What is the exact performance cost when mixing Ope

Question

I need to make a design decision of how to approach an app which needs to render few 3D objects on top of an image texture. Result needs to be rendered and saved as an UIImage. Graphical design (client) expects standard UIKit controls to manipulate 3D world.

OpenGL view (CAEAGLLayer layer) needs to be inside UIScrollView for cheap and natural scroll and zooming implementation. There are just few extra controls to manipulate rotation scale and transition of the few 3D objects. There is not many triangles expected (100-200 at most) and 2-3 textures (1 mask). It does not even have to be refreshed constantly, just when some transformations and zoom changes. CAEAGLLayer does not need to be opaque.

I would go with Core Animation solution but rendering 3D transformed CALayers to CGContextRef is not supported (neither is masking).

What is real performance cost when putting CAEAGLLayer inside UIScrollView and mixing it with few UIKit views? How much triangles per second can I expect to be rendered with smooth frame rate (30fps will do), so I can make the best decision possible?

I know there are similar questions out there already, but none of the answers provides specific numbers, which could help with estimating expected rendering results.

Answer 1

Per Allan Schaffer, who gives the WWDC and WWDC on tour OpenGL speeches, OpenGL itself is not so much a special case — it's that anything that changes will cause everything on top of it to be recomposited. I spoke to him specifically about an app with a live updating video view underneath a live updating OpenGL view and he said that sort of thing is the pathological worst case. It's generally not that expensive to throw a few quite static views on top, such as using a UILabel to display the current score over an OpenGL game.

In your case, I think you can probably largely avoid the problem. Don't put the GL view inside the scroll view, but rather make the scroll view non-opaque and put the GL view behind it. Catch scrollViewDidScroll: (and the corresponding zoom messages) and make related OpenGL adjustments. I can speak from experience and say I've done exactly that on an iPad 1 with no performance issues. Particularly for the sort of model you're talking about I don't imagine a problem.