iOS: Core image and multi threaded apps

Question

I am trying to run some core image filters in the most efficient way possible. Trying to avoid memory warnings and crashes, which I am getting when rendering large images. I am looking at Apple's Core Image Programming Guide. Regarding multi-threading it says: "each thread must create its own CIFilter objects. Otherwise, your app could behave unexpectedly."

What does this mean?

I am in fact attempting to run my filters on a background thread, so I can run an HUD on the main thread (see below). Does this make sense in the context of coreImage? I gather that core image inherently uses GCD.

//start HUD code here, on main thread

// Get a concurrent queue form the system
dispatch_queue_t concurrentQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(concurrentQueue, ^{

    //Effect image using Core Image filter chain on a background thread

    dispatch_async(dispatch_get_main_queue(), ^{

        //dismiss HUD and add fitered image to imageView in main thread

    });

});

More from the Apple Docs:

Maintaining Thread Safety

CIContext and CIImage objects are immutable, which means each can be shared safely among threads. Multiple threads can use the same GPU or CPU CIContext object to render CIImage objects. However, this is not the case for CIFilter objects, which are mutable. A CIFilter object cannot be shared safely among threads. If your app is multithreaded, each thread must create its own CIFilter objects. Otherwise, your app could behave unexpectedly.

Dryfoos

Answer 1

I'm not sure how to say it differently: Each background thread needs to create it's own version of the CIFilter objects in your filter chain. One way to achieve this would be to make a copy of your filter chain for every background operation you dispatch_async(...). In the code that you posted that might look something like this:

//start HUD code here, on main thread
// Assuming you already have a CIFilter* variable, created on the main thread, called `myFilter`
CIFilter* filterForThread = [myFilter copy];
// Get a concurrent queue form the system
dispatch_queue_t concurrentQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(concurrentQueue, ^{
    CIFilter filter = filterForThread;

    // Effect image using Core Image filter chain on a background thread

    dispatch_async(dispatch_get_main_queue(), ^{

        //dismiss HUD and add fitered image to imageView in main thread

    });

});
[filterForThread release];

What happens here is that filterForThread is a copy of myFilter. Referencing filterForThread in the block you pass to dispatch_async will cause that block to retain filterForThread, then the calling scope releases filterForThread, which effectively completes the transfer of conceptual ownership of filterForThread to the block (since the block is the only thing left with a reference to it). filterForThread can be thought of as private to the thread where the block is executed.

That should be enough to satisfy the thread safety requirements here.

Kosey

Thanks. I will read your answer a few dozen times and perhaps it wil sink in :). – Dryfoos

Here's an analogy: If you were writing a paper, and you wanted 5 different people to review/edit it for you (at the same time), you wouldn't make one print out, put the 5 people around it, and have them try to make edits simultaneously; You'd make 5 copies, and give each reviewer/editor the their own. Same idea here. You're giving each thread it's own copy of the CIFilter. – Kosey

Just wanted to say thanks, this saved me a bunch of time and reworking of other solutions. It works really well to handle filters in the background while keeping the UI moving. – Counterpressure