OpenGL ES multithreading and EAGLSharegroup
2013-02-20 14:28 三戒1993 阅读(149) 评论(0) 编辑 收藏 举报Q: In my multithreading OpenGL ES application, I load textures (or vertices) on a secondary thread then draw them onto screen on the main thread. Occasionally I see blank images or application freezes. What could be causing this?
A: In my multithreading OpenGL ES application, I load textures (or vertices) on a secondary thread then draw them onto screen on the main thread. Occasionally I see blank images or application freezes. What could be causing this?
It is very likely that the main and background threads are accessing the same OpenGL ES context simultaneously.
OpenGL ES commands for a specific context are not reentrant. You should never have more than one thread accessing a single context at the same time. It is highly recommended that you use only one thread per context.
Listing 1 demonstrates how to create and make current a context contextB
using the sharegroup
property
(an EAGLSharegroup
object) obtained from another already-allocated contextcontextA
. Such
contexts that belong to the same sharegroup can share resources, for example, textures, FBOs, etc. So you may use contextB
on the secondary thread to create textures, andcontextA
on
the main thread to draw the textures onto screen.
Listing 1 Creating a context belonging to the same sharegroup
contextB = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1 sharegroup:contextA.sharegroup]; if (!contextB || ![EAGLContext setCurrentContext:contextB]) { // Handle errors here } |
Important: The only way to get a valid EAGLSharegroup
object is to query it from an existing EAGLContext
object.
Any other method, such as explicitly creating it, will result in crashes or undefined behavior.
When you want to modify a resource on one context, you must first make sure it is not currently in use on another, even if you are accessing them from different threads. Once you modify it, its state is undefined until flushing and binding the object have been completed. You should never use an undefined object, whether you access it from a different context or not.
Take a texture as an example. Listing 2 shows the correct way to deal with multiple contexts. Any other ordering will not ensure consistent and correct behavior. It may result in data corruption, leaks, or crashes otherwise.
Listing 2 Modifying a texture on context B prior to using it on context A
// 1. Ensure context A is not bound to the texture [EAGLContext setCurrentContext:contextA]; glBindTexture(GL_TEXTURE_2D, 0); // 2. Call flush on context A glFlush(); // 3. Modify the texture on context B [EAGLContext setCurrentContext:contextB]; glBindTexture(GL_TEXTURE_2D, texId); // // Modify the texture data here // // 4. Call flush on context B glFlush(); // 5. Rebind the texture on context A [EAGLContext setCurrentContext:contextA]; glBindTexture(GL_TEXTURE_2D, texId); // 6. Use the texture as normal on context A |
For more information on the EAGLContext/-initWithAPI:sharegroup:
API and the sharegroup
property,
see the EAGLContext
Class Reference.
版权声明:本文为博主原创文章,未经博主允许不得转载。