According to Apple’s OpenGL ES Programming Guide, “If [a] framebuffer is intended to be displayed to the user, use a special Core Animation-aware renderbuffer.”
The text goes on to say that to make this Core Animation aware renderbuffer, one needs to “Subclass UIView to create an OpenGL ES view for [the] iOS application [and] Override the layerClass” by using this code:
+ (Class) layerClass
{
return [CAEAGLLayer class];
}
However, if one examines Apple’s GLCameraRipple example which displays OpenGL to the end user, the layerClass never appears to be overridden. A text search on layerClass or CAEAGLLayer reveals they are missing.
If you look for other approaches to display directly to users, Apple gives two other OpenGL approaches, but both seem to imply that they are not for displaying directly to users but rather are for off-screen rendering. (i.e. “If the framebuffer is used to perform offscreen image processing, attach a renderbuffer. If the framebuffer image is used as an input to a later rendering step, attach a texture.”)
Is there another way to display OpenGL content than using a Core Animation aware renderbuffer – or is Apple somehow overrriding the layer class so the OpenGL content is becoming Core Animation aware in another way?
The reason you don’t see a subclassed UIView with a CAEAGLLayer backing it in the GLCameraRipple example is because it uses a GLKView. GLKView is a class introduced in iOS 5.0 as part of GLKit, and it wraps some common code, such as the explicit override to use a CAEAGLLayer and the setup of its matching renderbuffer.
This is still being done, it’s just abstracted away from you. For displaying OpenGL ES content to the screen, you still need to go through a CAEAGLLayer one way or another.
Offscreen rendering is a different animal, because there you aren’t attaching to a layer for display, so there’s no layer needed. If you want to render to a texture, attach a texture as a target for your FBO, and that’s it.