GPUImage: EAGLContext and thread queue

Question

Recently I'm improving my OpenGL ES skills looking into the source code of GPUImage . While I was reading the code for the GPUImageContext class I get that it stores a reference to a queue that it's used in other parts of the library.

For example in GPUImageView.m the queue is used in commonInit with runSynchronouslyOnVideoProcessingQueue to perform some operations not directly related with the context (like adding attributes to the shader).

My question is why the developer has decided to perform these operations on a "secondary" queue and which is the benefit of storing this queue into a class like the GPUImageContext .

I know that question is strictly related with the GPUImage framework, but I think that it could be a big opportunity to understand how a skilled developer as Brad Larson has decided to structure one of the most famous library for Image Manipulation in iOS.

Ps I hope I didn't offend the author with my curiosity.

Answer 1

The reason for this is to provide a degree of thread safety. An OpenGL ES context can only be safely accessed from one thread at a time. To that end, I use a serial dispatch queue that I associate with the OpenGL ES context and dispatch anything that touches that context on that queue.

The use of a serial dispatch queue is an efficient means of ensuring only one thing at a time touches a resource. It avoids the overhead from expensive locks, and makes it easy to perform processing operations on a non-main thread.

You could elect to do all this only on the main thread, which is what I did at first, but that had some disadvantages. Slow processing can block the UI. Doing OpenGL ES rendering on a background thread has significant performance advantages, ranging from a 10% speedup on even single-core devices, to an over 40% speedup on multicore iOS hardware. You're also protected against instances where a developer using the framework accesses it from a non-main thread.