I want to use only a few filters within GPUImage2 in my swift project, how can I tailor GPUImage2 to only a few filters that I need?
I am not familiar with the code base, and I don't see any documentation on this.
P.S. My concern is mostly about app size, if including everything doesn't bloat the app size, I am OK with importing GPUImage as a whole.
This is a common question for people who want to shrink their binary size by only bringing over the operations they need, so I'll see if I can provide a canonical reference.
The easiest way to do this is to remove the dependency on GPUImage from your project and instead manually copy into your project just the files necessary to build the core components of the framework. The platform-independent core files are these:
CameraConversion.swift
SerialDispatch.swift
BasicOperation.swift
Color.swift
FillMode.swift
Matrix.swift
OpenGLContext_Shared.swift
Timestamp.swift
OpenGLRendering.swift
ShaderProgram.swift
ShaderUniformSettings.swift
Framebuffer.swift
FramebufferCache.swift
Position.swift
Size.swift
Pipeline.swift
ImageOrientation.swift
The following files also need to come over, but they have platform-specific (Mac, iOS, or Linux) variants, so you'll either need to choose the ones for your specific platform target or selectively include them to each of your various targets:
PictureInput.swift
PictureOutput.swift
MovieInput.swift
MovieOutput.swift
Camera.swift
OpenGLContext.swift
RenderView.swift
With those files, you should be able to build a project that can perform image processing in the same manner as GPUImage, but without the long list of operations. If you have one or two operations you want to bring over, you can selectively copy those files into your project. You might need to copy over one or two dependencies if they are subclassed from another operation.
Related
I would like a set of rules from my_package.bzl to be accessible to all BUILD files of a workspace without having to load my_package.bzl in the BUILD files. Basically I want the rules in the package to look like native rules. How can I achieve this?
I was thinking maybe there's a line I could add to one of the .bazelrcs or to the WORKSPACE file of the the project.
This can be achieved by adding a prelude_bazel file at //tools/build_rules:prelude_bazel (this must be a package, so tools/build_rules must contain a BUILD file).
This will be loaded and prepended to all BUILD files loaded by Bazel.
However, there are a few things to consider before going this route. It's currently undocumented, and while doing some searching to find any info on this feature, it's unclear if it will remain a part of Bazel.
It may also have performance / scaling problems. If the prelude were to change (or any of its dependencies), every BUILD file would have to be reloaded, and this may take some time depending on the size of the build graph.
I’m currently writing some custom Core Image filters using Metal. For the sake of structure I want to put the different kernels into different .metal files with some common includes like you would do with “normal” source files.
However, when the metallib tool bundles the different .air files created by the Metal compiler into one .metallib file, only the kernel functions defined in the first input .air file given to metallib are visible. Functions from the other .air files don’t seem to be included. What’s the reason for this?
I thought (as is the default compilation behavior for Metal files) all Metal sources get compiled into one library that is then used by every custom CIFilter class to instantiate their internal CIKernel with the function they need.
I now ended up compiling a .metallib file for each custom filter with custom build rules and copying all of them them into my framework using a custom build phase. This doesn't seem to be the intended way…
I'm very interested in using GStreamer's iOS framework http://docs.gstreamer.com/display/GstSDK/Installing+for+iOS+development for video streaming, but when I add the framework to a blank project and add a few lines of code to take advantage of its powerful features, the final IPA is 27MB. This is just way to big to be adding to my project, what is the best way to go about stripping this down the the bare necessities as I'm sure I'm only using a small percent of the code that is included in the SDK.
Here's a pic showing the package contents of the IPA:
Thanks!
In the gst_ios_main.h you can disable all the plugins that you don't need (make sure to enable linker optimizations so that unused code is removed). If that's not enough, you can build your own stripped down version of the iOS binaries with http://cgit.freedesktop.org/gstreamer/cerbero/ (you need to remove things from the .package and .recipe files to only build what you need). Just disabling things from gst_ios_main.h should be enough in 99% of the cases though.
Note that by default you'll build applications for multiple architectures, as such the resulting application will be rather large. Depending on your use case you can drop some architectures.
On another note, gstreamer.com is providing an completely outdated version of GStreamer and is in no way related to the GStreamer project. The official website is http://gstreamer.freedesktop.org .
SDKs have their source code encapsulated away from you, the user. You get access only to header files. Thus you just can't extract some class from it because you don't have access to the implementation file.
Of course if this library is opensource you can attempt to isolate one class, but sometimes everything is so deeply connected, that it is close to impossible.
I want to make multiple apps which share the same structure and code, but have different images, fonts, names and urls.
I would like a simple way to make this apps without replicating the whole project, so that when I find a bug I'll have to correct it only once.
Thank you.
PS: It isn't important the language (Objective-C or Swift)
Create multiple targets within the same project. You can then include or exclude asset catalogues, configuration JSON files etc. on a per-target basis. If you're consistent with the names this should get you most of the way there. You can also look at target-specific build flags or constants.
I am working in a very large iOS project and it has so many classes and resources that it takes very long time to index and compile them. As it still grows more and more, I need to do something about this because I am spending too much of my time waiting for the IDE to let me work.
My first idea was to pack all the images in a custom bundle so the IDE will see it as a single file and would be faster to index and copy it, but I have seen that a bundle is nothing more than a simple folder with an extension, so I guess that the performance would still be slow. Then I read that if I used "blue folders" instead of "yellow groups" for my images, Xcode would not index them. But this way is not easy right now, as I should replace my function that looks for images to look for them in that folder (absolute paths?)
So my last approach will be saving time in both compile time and indexing. I want to modularize my code in multiple libraries so it will not be necessary to compile it "ever" again and this way Xcode won't need to index the source files neither.
I have followed some tutorials and now I know how to create a static library and include the header files in another project. But my current problem is as follows.
My application has several "independent" modules, so I want to create a static library for each one (and maybe I'll generate an image bundle for each one too...). But all of those modules use a common core, which I'd like to maintain in a static library too. So, if I do it like this, I will have to include the main core library in every module library, and I'm afraid this will not be the most optimum way, as the binary code of the core will be there several times, right?
I guess the correct solution would be to generate a dynamic library for the core and static ones for the modules, but I can't find how to generate the dynamic one... Furthermore, I'm not sure this would be the solution.
So I ask you: what options do I have? Is compiling the core several times the best approach I have?
Thank you so much for your help!
Dynamic linking is not supported in IOS, so this isn't an option. While the static libraries are added to the other libraries, it isn't embedded inside the other static library, you can see this when you do a build, the other libraries should show as a separate libraries inside the project folder, hence each static library/project will only get included once in the app build.
In the end ... I am not sure this will save you a lot of time you are expecting if you are using static libraries in the same workspace. I use static libraries in some projects and if I do a Clean on the app, then a build, the static library will get re-built also.