How to know when to use UIViews and other Quartz2d features and when to use OpenGL ES?

Question

When starting a new 2d project on the iOS framework, it seems pretty to start creating UIView subclasses and having fun with Quartz to create very quick prototypes, but I am guessing there will be times where it will be impractical(or impossible) to use such powerful(and wasteful compared to openGL ES) abstractions.

I know a couple dozen subviews work allright, but there must be a point where having more than X is just impossible to keep a good frame rate.

How do you know if it would be a good idea to drop the UIKit and start doing some more powerful stuff on openGL?

Answer 1

In my own game I use a combination of UIKit and Cocos2D (which is OpenGL ES based, for those not familiar with it).

The first iteration of my game used UIKit for menus, and then a game screen that was Cocos2D based. The game screen had buttons on it, as well as dialog messages that would pop up. These were all done in Cocos2D.

Over time, I have gradually replaced much of my Cocos2D code with UIKit, so that the game play screen is about 2/3 Cocos2D and 1/3 UIKit.

I have learned to love and use both frameworks for different reasons.

This has several advantages:

1) It's easier to have a consistent UI throughout the app. I was having to write code that would make my shiny UIKit buttons look just like my shiny Cocos2D buttons. Now they're all UIKit.

2) The UIKit API is stable. The best thing and worst thing about Cocos2D is that it is changing (improving!) so fast that I found myself constantly updating my code to support new features and API changes. Now the amount of code that gets affected by those changes is a lot smaller.

3) I have seen no performance loss by doing it this way. There may even be some memory gain because UIKit is pretty efficient with its use of resources when memory gets tight.

4) Development on things like pop-up messages and dialogs is a lot faster, because I can do those in Interface Builder. I don't need to think about how to lay out the dialog screens in code.

5) I don't have to reinvent the wheel on basics like buttons and tables.

After developing this way, here's my rule of thumb:

1) Use UIKit for everything that doesn't require OpenGL. Menus, messages, buttons, tables, etc. Core Animation does a good job on 80% of what I need.

2) If I find myself writing something that I have seen in UIKit, stop and try to think how I can pull it out of the OpenGL view.

3) Certain things like complex movement, particle effects, etc. are perfect fit for OpenGL/Cocos2D, so that's where I put that effort.

Answer 2

Isn't Quartz2D more for User Interface / Charts / Drawing Shadowed Text?

It depends on what you're building. I've built game projects using Core Animation and I've just now started to dip into Cocos2D/OpenGL ES. The most I was doing in my projects was scrolling a background and allowing the player to manipulate views (drag and drop). The moment I thought about particles I figured I would slow the system down to a halt. Animations seemed to work well enough. But, again, I wasn't doing much.

If your game is simple enough you could very well ride with Quartz2D. But if you're thinking about 50 enemy ships and particle effects already, I'd look at OpenGL ES and save yourself the headache. Might as well learn it earlier rather than later.

I have to look at projects like Cocos2D and think that OpenGL ES would be the better route to go if you are serious about developing some graphical intense game projects.

Answer 3

I would say that it's time to switch when you run into something you can't do or it's too slow. Switching anytime before then is just wasted time. And if you are doing this for yourself, you don't want to waste a lot of time.

As for the speed of UIViews, I've found them to be very respectable -- you're not going to want to use them to put up 100s of sprites and particles on the screen at once, but there are certainly quite a few games you could get away with using nothing outside of Cocoa. If you find yourself on the edge, you can use CALayers directly to reduce some overhead.

Another thing to remember is that the OS caches the contents of your layers. Even if the item beneath a layer is redrawn and that layer has transparency in it, it doesn't mean that layer will be redrawn. I've watched layers in my code to see how often their drawInContext: method is called, and despite tons of things going on, most of the time it will be once. The OS does a very good job with minimizing draw calls.

Answer 4

I've found that trying to maintain even 20 FPS with UIKit is difficult when you have more than 10-15 moving objects. Adding and removing UIviews is also slow, and keeping the necessary uncompressed UIImages in memory is expensive.

Probably good for puzzle or board games, but go with Cocos2d for anything with more moving parts.