'resize' orientation change bug on Sony Xperia Z

Solar2D Android
#1

Hi, despite the fact that the ‘resize’ method should kill the orientation change bug on tablets with Android 4, I’m still having orientation change issue on Sony Xperia Z tablet with android 4.3. I use the ‘resize’ method, but still my content changes weird - I have margins remaining on both sides of my Sony display. What am I doing wrong? I’m using the latest daily build from yesterday (29th May 2014).

 

Here’s my resize method:

local function onResize2( event ) \_W = display.contentWidth \_H = display.contentHeight if back then back.x, back.y = \_W\*0.5, \_H\*0.5 end if webView then webView.width = \_W webView.height = \_H-40 menuBack.width, menuBack.height, menuBack.x,menuBack.y = \_W, \_H-40, \_W\*0.5, \_H\*0.5+20 webView.y = \_H\*0.5+20 headerBack.width = \_W headerBack.x = \_W\*0.5 headerLogo.x = \_W\*0.5 end end -- Add the "resize" event listener. Runtime:addEventListener( "resize", onResize2 ) 

and here’s my config.lua scaling:

--calculate the aspect ratio of the device: local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 320 or math.ceil( 480 / aspectRatio ), height = aspectRatio \< 1.5 and 480 or math.ceil( 320 \* aspectRatio ), scale = "letterBox", fps = 60, imageSuffix = { ["@2x"] = 1.5, ["@4x"] = 3.0, }, }, }

please help   :( When I launch the app vertically it’s fine, when I launch the app horizontally it’s fine. But when I change the orientation - the other orientation always appears with margins, like it was setting the new display.contentWidth to small than it actually is.

 

Does anyone has any ideas what’s happening here?

It’s pretty urgent   :frowning:

Cheers,

 

PS. I tried also using display.viewableContent* values but it’s the same

#2

I spoke with one of our engineers and it could be a content scaling issue.  The bottom nav bar changes in size and that could be effecting the scaling.  I don’t know that the values in config.lua get re-done.  If I’m reading the help page correctly, all we do is swap the display.contentWidth and display.contentHeight values.  Because showing or hiding that nav bar, or it’s moving from bottom to the side on earlier version of android or the change in height alter the aspect ratio of the screen. 

You cal try to access display.actualContentWidth and display.actualContentHeight and see if they give you better results. 

Rob

#3

Hi Rob, I tried the actualContent values as well but with no success. The bottom bar you are mentioning is probably causing the problem. The thing is that the resize method was introduced to kill that bug. According to Joshua’s declarations in this thread:http://forums.coronalabs.com/topic/32916-android-orientation-switching-broken-on-nexus-7-style-displays-due-to-navigation-bar/?hl=%2Bresize+%2Bjoshua#entry171493Could you please ask engineers if they could look at the resize method again? It’s quite a serious bug if you don’t support multiple orientations on tablets with android 3 or 4 :confused: Thanks,

#4

Can I get you to put together a complete test app that the Engineers can use to to test this (build.settings, config.lua, assets needed to recreate it) and file a bug report on it?

Thanks

Rob

#5

Just did report it with the code attached. Could Corona engineers or you let me know when they look into it?

I look forward for a fix to come. My client is totally mad on me due to this orientation limitation :frowning:

#6

Can you post the bug number that was emailed to you back here as a reference?

Thanks

Rob

#7

It’s Case 33251.
Thanks!

#8

Okay I downloaded your test app.  Thanks for providing it.  I see what’s going on and I’m talking with engineering about the issue, but basically when it rotates, it adjusts for the moving nav bar by adding width to the content area vs, taking it away from the height so that the one dimension stays 320 the whole time (based on your config.lua).  This cause the display.screenOriginX to shift from 0 to -37 (half the height of the nav bar).  I got your app to behave the way it should by **adding** the value of display.screenOriginX to all of your .x’s in your webView rotate area.  You will probably need to make sure you get everything.

At least you can use this to work around the problem.

Rob

#9

Hi Rob, thanks for looking into it! Could you email me your version of the code, please? I’m not sure if I understood right what you said:
whammy [at] poczta [dot] onet [dot] pl

Nevertheless, engineers should fix the problem on Corona side also, right?

Also - from what you write I’m assuming that you have a margin visible only on the right side (originX shifted to left), while on my tablet I have margins remaining on both sides equally.

Thanks,

#10

@Rob, but isn’t the work-around-solution you’re proposing good only for tablets with android 4 (bottom nav bar appearing), but when I launch the app on a smartphone - the webView with added value would be to wide with some content hidden outside of the screen? :/ 

#11

First I don’t know that this is a bug.  When the nav bar moves, the space it takes up has to come from somewhere.  In my case, my Nexus 7 is a 800x1280 screen (1.6 aspect ratio).  When you set the content area to 320 x 480 like you are, the screen when scaled becomes 320x512.  Take out the space for the nav bar and you send up with 320x482 for your usable content area.  When you rotate it, you’re available width is now back to 512 (there are some fractional values here, I’m rounding up for ease of communications). 

Because the content area you asked for in this case was 480px, the difference gets padded on the sides, but you told your config.lua that you wanted a 480px wide content area.  This causes that 480px to get centered in side the 512px box, in effect letterboxing the sides since you’re only intending on drawing the expected 480px width. 

For people who do not use the Ultimate config.lua that you’re using, who use a fixed sized area, they already manage this extra letter boxing by using the values for display.screenOriginX to position things. 

This should work on any device because we are going to provide the right value for these items.  

Rob

#12

@Rob, you were right - adding the value of display.screenOriginX here and there did the trick. Thanks for your help! 

Cheers,

#13

This is not a Corona bug. Your app is using Letterbox scaling mode and using display.actualContentWidth and display.actualContentHeight to fill out the letterbox areas with your assets. Your app is also using the same APIs to center the assets on screen – which is wrong because Corona’s 0,0 reference point is not the edge of the screen but the end of the top left letterbox area. This is why your content is shifted to the right. The proper solution is to either use display.contentWidth and display.contentHeight to center the assets or to add in the letterbox offset using display.screenOriginX and display.screenOriginY to the actualWidth and actualHeight values.

The other issue your app has is trying to dynamically set the Width and Height in config.lua by computing the “aspect ratio” based on display.pixelWidth and display.pixelHeight. As I showed you in your bug case, these values will change on Android devices that resize the tab bar based on orientation (e.g., Nexus 7). With your app I saw the aspect ratio change from 1.7 to 1.5 depending on the startup orientation. This will cause issues when you try to support rotating to different orientations.

Corona does support the resizing on these devices but NOT when  you try to dynamically change the Width and Height in config.lua based on your computed aspect ratio. It’s fine to change it based on device types but not based on native pixel sizes on devices where this can change because of startup orientation.

#14

Tom, I was trying to use both actualContentWidth, viewableContentWidth AND actualWidth - all of them drew the same result. Which in my case wasn’t shifting to the right, but drawing margins on both sides while the content was centered.

Regarding a letterbox mode and ‘tricks’ I’m using in config.lua file - I’m just following Rob’s articles (modernising config lua) where the only mode considered in examples was the letterbox mode, so I thought it was a GOOD one :wink:

Adding screenOriginX value did the trick, but IMHO it should be automated during the build. So while it’s not a Corona BUG, maybe, it might be sth worth considering to add in future daily builds.

Anyway, thanks for looking into it.

#15

There are many ways to handle the config.lua.  No one setup will work for every condition.  In this case, the ultimate config.lua is great for making your content area fit the screen on many different devices but there are conditions like trying to support rotating layouts  that it doesn’t work all that well for.  I don’t believe that the config.lua gets reprocessed on rotation.

At least we found a way to work around it.

Rob

#16

We’ve talked this over internally and there is nothing we can add to the build that would help you. Android does NOT supply the height of the navigation bar nor does it tell us that the device uses a navigation bar. We only get the screen size based on the device orientation when the device is first started. Those are the numbers we pass along to the app using display.newPixelWidth and display.newPixelHeight. With Android devices that use navigation bars that consume screen real estate, those numbers MAY changed based on app startup orientation.

When you specify letterbox mode, that is based on display.contentWidth and display.contentHeight and the screen origin is adjusted to compensate for the letterbox area. When you use display.actualContentWidth and display.actualContentHeight to position objects, you are bypassing the mode you enabled for positioning your app and need to adjust the location so everything is aligned correctly.

#17

I spoke with one of our engineers and it could be a content scaling issue.  The bottom nav bar changes in size and that could be effecting the scaling.  I don’t know that the values in config.lua get re-done.  If I’m reading the help page correctly, all we do is swap the display.contentWidth and display.contentHeight values.  Because showing or hiding that nav bar, or it’s moving from bottom to the side on earlier version of android or the change in height alter the aspect ratio of the screen. 

You cal try to access display.actualContentWidth and display.actualContentHeight and see if they give you better results. 

Rob

#18

Hi Rob, I tried the actualContent values as well but with no success. The bottom bar you are mentioning is probably causing the problem. The thing is that the resize method was introduced to kill that bug. According to Joshua’s declarations in this thread:http://forums.coronalabs.com/topic/32916-android-orientation-switching-broken-on-nexus-7-style-displays-due-to-navigation-bar/?hl=%2Bresize+%2Bjoshua#entry171493Could you please ask engineers if they could look at the resize method again? It’s quite a serious bug if you don’t support multiple orientations on tablets with android 3 or 4 :confused: Thanks,

#19

Can I get you to put together a complete test app that the Engineers can use to to test this (build.settings, config.lua, assets needed to recreate it) and file a bug report on it?

Thanks

Rob

#20

Just did report it with the code attached. Could Corona engineers or you let me know when they look into it?

I look forward for a fix to come. My client is totally mad on me due to this orientation limitation :frowning: