iOS Device Orientation Discussion

[masterfalcon]

While working on some fixes for device orientation I've had a few ideas and some more questions. Some of these I don't feel making assumptions about without input from the community. The problem is how many ways there are to specify orientations. Value in ogre.cfg(both in app bundle and stored in Documents dir), the UIInterfaceOrientation info.plist key, and the UISupportedInterfaceOrientations info.plist key.

All 3 are defined by the developer. UISupportedInterfaceOrientations is used to limit which orientations are supported and it's usage within Ogre is pretty straightforward. The first two are problematic. What should be preferred? Should it be preferred for the first launch or for all app launches? Furthermore, should the device orientation be saved in ogre.cfg(I think it should) and should that value trump everything else?

The first and most important issue is: How much of this decision should be made by the graphics engine and how much is application specific logic?

Here is what I'm proposing.

Upon first launch, some orientation needs to be used. Because the majority of people are right handed and most apps will use a landscape view, I think the default should be Landscape Right(with the Home button on the right side).

If the developer provides an ogre.cfg file, then whatever orientation(if there is one) should be preferred over anything else. UIInterfaceOrientation should just be ignored. On subsequent launches, the value in the ogre.cfg stored in the Documents folder would be used as the preferred value because this is how the user last saw the app.

This leaves a few questions: If the developer does not specify an orientation in ogre.cfg, then what should happen? If they do not specify UISupportedInterfaceOrientations then what should happen? Or should we make no assumptions about the initial orientation and just use something like Landscape Right?

Over the past week or so I've come to realize that this is a way more complex issue than I'd initially thought and certainly requires input from more brains than mine.

[Gwl]

FWIW, I have been trying to get 1.8 behave nicely with UIKit based app and ran into these issues. If done correctly, OGRE should't need to worry about orientation at all - assuming the view is put into view controller and shouldAutorotateToInterfaceOrientation is properly defined, iOS handles the rotation automatically. EAGLView gets the information by defining layoutSubviews and allocating color buffer with new width and height there. I think default Xcode OpenGL template shows how it works. If using this method, I guess OGRE should be compiled with OGRE_NO_VIEWPORT_ORIENTATIONMODE enabled.

I don't know the decisions behind having viewport orientation modes etc in OGRE, but on iOS it would make things more straightforward to use this builtin mechanism the OS provides. Otherwise all those who use UIKit will need lots of hacks to get things working. On iPad it's mandatory to handle left and right (or up/down) orientation change on the fly.

[warmi]

FWIW, I have been trying to get 1.8 behave nicely with UIKit based app and ran into these issues. If done correctly, OGRE should't need to worry about orientation at all - assuming the view is put into view controller and shouldAutorotateToInterfaceOrientation is properly defined, iOS handles the rotation automatically. EAGLView gets the information by defining layoutSubviews and allocating color buffer with new width and height there. I think default Xcode OpenGL template shows how it works. If using this method, I guess OGRE should be compiled with OGRE_NO_VIEWPORT_ORIENTATIONMODE enabled.

I don't know the decisions behind having viewport orientation modes etc in OGRE, but on iOS it would make things more straightforward to use this builtin mechanism the OS provides. Otherwise all those who use UIKit will need lots of hacks to get things working. On iPad it's mandatory to handle left and right (or up/down) orientation change on the fly.

There is some performance penalty associated with letting UIKit handle the rotation .. it is not as bad in terms of performance in the latest iOS but it is still there.
Of course, if you are using UIKit on top of GLES then perhaps it makes sense but some apps don't do that ( and btw it is not mandatory to switch orientations on iPads as long as your app is a game)

[Gwl]

There is some performance penalty associated with letting UIKit handle the rotation .. it is not as bad in terms of performance in the latest iOS but it is still there.
Of course, if you are using UIKit on top of GLES then perhaps it makes sense but some apps don't do that ( and btw it is not mandatory to switch orientations on iPads as long as your app is a game)

According to http://developer.apple.com/library/ios/ ... texts.html the performance should only be an issue for MBX hardware, so ES2 pipeline wouldn't be affected. Furthermore, with iAd, GameCenter and others it's reasonable to assume that a big percentage of apps will need UIKit for some of their functionality. Even the most basic ones do in form of touch event processing which requires manual coordinate translations when not using autorotation.

As for mandatory switching in iPad, it's true that you don't need to support both landscape and portrait, but you do need to support both variants (eg. left/right for landscape), unless something has changed in the approval process recently.

[masterfalcon]

Perhaps the best way to deal with it would be to perform any view resizing duties inside -layoutSubviews. It gets called automatically if using a view controller and if an app is not using one but still wants to support changing orientations they just need to call -setNeedsLayout on either the window or EAGLView itself. I feel that this will provide the most passive and comprehensive way for Ogre to fit in with whatever a developer wants to do. What do you guys think?

[pratty70]

I've actually written this into my system. I handle orientation changes myself by looking at the accelerometer directly and then create a rendertexture of my camera view which i rotate - when it's rotated I create a rotated viewport in Ogre to realise the orientation change.

It certainly seems the case that the UIKit integration's performance hit is on older iOS/devices and is less consequential on newer iOS/devices. I would prefer UIKit to do it - as then integration with UIKit itself is much easier - and although not necessary - I have applications where integration is a good thing. It's certainly tricky as I see there are people who would not want to.

Does this need to be something that's "built-in" to Ogre - or should we be prepping a good base example of EAGLView manipulation outside the engine as a template to performing orientation changes.

As for touch information, that would also be interesting - that would also need knowledge of orientation for injecting touch position.

Am I understanding what you're asking?

[masterfalcon]

Yeah, I think you're on to it. I want to make sure that Ogre does rotate properly, but I don't want it to be in charge of rotation. I realize that that should be the responsibility of the application.

So for example, if one is using a view controller, the Ogre view will have it's (not yet implemented) layoutSubviews method called automatically when a rotation occurs. If you aren't using a view controller then you can do something like become an observer of UIDeviceOrientationDidChangeNotification's for example and then call setNeedsLayout on Ogre's view or window when you detect that an orientation change has occurred.

[warmi]

Yeah, I think you're on to it. I want to make sure that Ogre does rotate properly, but I don't want it to be in charge of rotation. I realize that that should be the responsibility of the application.

So for example, if one is using a view controller, the Ogre view will have it's (not yet implemented) layoutSubviews method called automatically when a rotation occurs. If you aren't using a view controller then you can do something like become an observer of UIDeviceOrientationDidChangeNotification's for example and then call setNeedsLayout on Ogre's view or window when you detect that an orientation change has occurred.

Good idea.

[pratty70]

ditto. I agree. Sounds like a plan.

[masterfalcon]

On a related thought. View Controllers.

Build one into Ogre? I'm inclined to say no. So that leaves creating one yourself and passing it into the window system. The GL and DX rendersystems already have support for externally created windows or views and this is similar, in concept.

There are a couple thoughts that I've come up with.

• Externally created view controller - to deal with auto rotation, etc.
• Externally created view - useful for using Ogre to render to a subview instead of the whole screen, best suited for the iPad. As these devices get more powerful in the future, this will likely become a more useful feature and more common request.

Anything else to add? Any thoughts? I should also say that these changes will be going into 1.8, as they will require too much change for the stable branch.

[pratty70]

I'll have a think over the weekend if there's anything I want to add. Had a busy week this week.

[CoolFaer]

When we create ios window why we set status bar orientation to left for right and right for left? So, then i want to show standart message box or virtual keyboard, them orientation is incorrect, now. For resolve this problem i had to create this patch: https://sourceforge.net/tracker/?func=d ... tid=302997