I am looking into converting my OpenGL rendering code to take advantage of a few features of GLKit (namely the asynchronous texture loading and the automation provided by GLKView/Controller). However, it appears that the classes are designed mainly to accommodate people rendering using an animation loop, whereas I’m working with on-demand rendering. Additionally, some of the rendering is to a texture rather than the GLKView’s framebuffer, so should I be looking to just subclass the GLKView and add additional FBOs?
Is there a recommended approach for this type of setup? I would expect something along the lines of:
- Set the view controller’s
preferredFramesPerSecondto0, or just
pause the frame updates? - Ignore the
glkViewControllerUpdateorglkView:drawInRect:methods
and just draw what I need, when I need it. - Use the view’s
setNeedsDisplayas with a normalUIViewin order
to display the frame (do I need to callbindDrawablegiven that I
will be rendering to a texture as well?).
Perhaps it’s not worth the effort if this is not what the new API is designed for? I wish the documentation was a little more thorough than it is. Perhaps more samples will be provided when the API has ‘matured’ a little…
Thanks
The approach I ended up using was to not bother with the
GLKViewController, but just useGLKViewdirectly under aUIViewControllersubclass.Clearly, the
GLKViewControlleris intended for use by people who need a consistent rendering loop for apps such as games. Without it, drawing to theGLKViewis as simple as calling[glkView setNeedsDisplay]. Be sure to setenableSetNeedsDisplaytoYESin order to enable this behaviour.If you did still want to make use of a
GLKViewController, you can disable the animation rendering loop inviewWillAppearlike so:Also, set
resumeOnDidBecomeActivetoNOto prevent the view controller from resuming again automatically.Using a plain
UIViewControllerwith aGLKViewis perfectly acceptable however, and I have seen it recommended by an Apple engineer as an appropriate way to perform on-demand drawing.