开发者

Letting UIKit handle device rotation in OpenGLES 1.1 - is it actually any slower, and if so under what circumstances?

I've been letting UIKit handle the device rotation for me (my iOS app has a UIViewController that implements shouldAutorotateToInterfaceOrientation:) and I've been pretty happy with how straightforward it was to get it all working.

I've since been told though that this is slower than doing all the rotation business manually. This hasn't been borne out by my tests, however, either on an iPad (iOS 4.2) or an iPod Touch 2G (also iOS 4.2).

I was a bit surprised to b开发者_运维问答e told there would be a big difference anyway, as judging by how UIKit seems to work it doesn't look like there's any scope for OpenGLES to do a page flip. So -[EAGLContext presentRenderbuffer:] pretty much has to do a copy, which will take basically the same time regardless of rotation state. The overhead of the other aspects of rotation (general coordinate transforms, mainly) I'd imagine to be similarly negligible.

That's only my conjecture, though, and I have only my lying eyes to back it up! So are there cases where letting UIKit handle the device rotation does actually make a big difference? If so, what are they?


Using view controllers to handle rotation is the best and recommended solution on the following devices: iPhone 3GS, iPhone 4, iPad, iPad 2, iPod touch 3G, iPod touch 4G running iOS 4.2 and later.

If your application runs on any older iOS device, you should perform the rotation directly with OpenGL ES. Coincidentally, the devices on which this is recommended, are all devices that support OpenGL ES 2.0, and thus have their OpenGL ES 1.1 pipelines implemented using shaders.

If you'd like more information on how to handle the rotation on non-ES 2.0 devices, or confirmation of this answer, you'll find that here.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜