Hacker News new | ask | show | jobs
by winter_blue 4786 days ago
Wouldn't drawing with UIKit be less efficient than using an OpenGL backend?

SDL[1] on Windows for instance, falls back to GDL when proper DirectX support isn't available. GDI is what most GUI apps use to draw their elements on Windows. It is akin to UIKit on iOS. But GDI is horribly slow as all the computation is done on the CPU.

In fact, realizing this fact, Microsoft has recently developed Direct2D, which does the computation on the GPU and which regular GUI apps can use to achieve better performance. (BTW, I believe Direct2D is somewhat similar to Cairo 2D.)

[1] Simple DirectMedia Layer -- used by plenty of games to achieve cross-platform compatibility. Most games in the Humble Indie Bundle use this.

3 comments

Yep. While UIKit is going to draw using OpenGL anyway with this case you're missing a big optimisation in being able do batch drawing of the tiles and using VBO's etc.

UIKit is fantastic for normal UI's and the 'general case' but almost certainly isnt optimised for doing efficient drawing of a large number of sprites / tiles (trading efficiency for flexibility).

Couple years ago I actually wrote my own API compatible version of UIKit but backed by OpenGL , and then extended support for these type of cases. As it was basically a drop in replacement I was able to confirm UIKit (at least at the time) was not very clever or fast when it came to a large view hierarchy. So my fraemwork was optimising for large batch drawing from a single texture mostly which is what you really want in the OP's case.

I should release it one day as open source.. though is all OpenGL 1 so a little outdated on iOS these days.

> I should release it one day as open source.. though is all OpenGL 1 so a little outdated on iOS these days.

You definitely should! :-D

You can worry about porting/updating it later. You might even get help in doing so, once you open-source it.

Yes and no. The -(void)drawFrame call uses CPU, but almost everything else you do in UIKit is done in the gpu. (Everything that can be animated is done in the gpu)
This wasn't about efficiency for me. When I wrote this, I didn't know OpenGL, but I already knew how to work with UIKit.

I started with processing TMX files and Texture Packer files, just to see if I could get UIKit to load them. Once I had that working, I added virtual controls, basic dialog, and basic game state.