Home/ Questions/Q 8636341
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T10:12:41+00:00

I am working on a game where the rendering is done using GLKit. In

  • 0

I am working on a game where the rendering is done using GLKit. In order to save some work in creating UI layouts, I am using Interface Builder and UIKit views to manage the showing/hiding and interaction of certain interface elements.

Recently I made some structural changes that resulted in two fullscreen views containing my button overlays on top of the GL view, and this has hurt the rendering framerate on some slower devices such as iPhone 4 and 4th Gen iPod Touch. I did this to make it easier to show/hide full control layouts all at once using the existing IB/UIKit architecture.

Old:

|-Root (GLKView)
|  |-Buttons

New:

|-Root  (GLKView)
|  |-Layout 1
|  |  |-Buttons 1
|  |-Layout 2
|  |  |-Buttons 2
(Etc...)

The overlays (Layout 1, 2, …, n) are completely transparent, contain a few subviews (Buttons 1, 2, …, n) with images and text around the edges of the screen. The overhead for overlaying these few buttons and things was not as bad when the views were direct descendants of the root view, but with an extra transparent view in the middle seems to have added sapped my performance, as my framerate decreased a lot.

What sorts of options do I have for reducing overhead? There’s no animation or anything happening in the overlays, so I assume they shouldn’t be redrawing more than they need to, and it could just be the extra alpha-blended full-screen overlay that is sapping my performance.

I am setting the hidden properties on all of my UIViews every frame without checking whether they have changed, could that result in the views being flagged as needing a redraw?

Converting all these buttons to OpenGL drawing is possible since I’m not using iOS’s native controls like UIButtons and UISwitches (Just UIViews with images and labels), but I’d like to avoid it if I can.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The cost emanates up from the OpenGL view rather than down from the buttons; when it changes everything on top needs to be recomposited.

    So in terms of a practical solution, how about ditching the layout views and using IBCollections instead? You’d definitely want to push changes the hidden flags only on actual changes to avoid array iterations but you’d get the same overall compositing costs as previously.

    So you’d declare something like:

    @property(retain) IBOutletCollection(UIView) NSArray *viewsInLayout1;

    You can then wire that to as many views as you like in the interface designer. Subsequently in code you’d have the array viewsInLayout1 that you could iterate through (or use makeObjectsPerformSelector: where possible) to differentiate one group from another without having to hardcode the groupings all over the place.

    • 0