EAGLContext, EAGLSharegroups, RenderBuffers, FrameBuffers, oh my!

Question

I'm trying to wrap my head around the OpenGL object model on iPhone OS. I'm currently rendering into a few different UIViews (build on CAEAGLayers) on the screen. I currently have each of these as using separate EAGLContext, each of which has a color renderbuffer and a framebuffer.

I'm rendering similar things in them, and I'd like to share textures between these instances to save memory overhead.

My current understanding is that I could use the same setup (some number of contexts, each with a FBO/RBO) but if I spawn the later ones using the EAGLShareGroup of the first one, then I can simply use the texture names (GLuints) from the first one in the later ones. Is this accurate?

If this is the case, I guess the followup question is: what's the benefit to having it be a "sharegroup"? Could I just reuse the same context, and attach multiple FBOs/RBOs to that context? I think I'm struggling with the abstraction layer of a sharegroup, which seems to share "objects" (textures and other named things) but not "state" (matrices, enabled/disabled states) which are owned by the context.

What's the best way to think of this?

Thanks for any enlightenment!

Answer 1

That’s correct—when two EAGLContexts are created with the same EAGLSharegroup, they share the same view of buffer objects, textures, renderbuffers, and framebuffers. If your contexts are using OpenGL ES 2.0, they’ll share shaders and program objects as well.

One of the biggest use cases for multiple contexts using the same sharegroup would be the ability to load resources asynchronously from another thread while you’re rendering. That doesn’t seem like what you’re doing here, and it doesn’t seem like having persistent context state is an issue for you, so you might be better off sticking with a single EAGLContext and just stashing the reference to it somewhere where all the objects that might need it can see it. You’d be able to change which views you’re rendering to simply by binding the appropriate framebuffer and color renderbuffer.