Simple question. I would assume that in landscape, display.actualContentWidth would be greater than display.actualContentHeight. This is not the case. I can work around it, just curious if this is intentional and if so what the logic is.
Happy to report a bug if necessary, using 2013.3.13
As I understood it, contentWidth and contentHeight always report the portrait dimensions of the screen even when using different orientations, so you could roll your own orientation-sensitive values. It appears that actualContent* are the same thing, only in Corona Units instead of pixels. A page describing the difference (as well as orientation handling) is probably a good idea though.
if I start my app in landscape mode it def reports landscape vals for contentWidth/contentHeight so it’s inconsistent if not a bug
I like your page idea … would be great if they showed the diagram from here but pointed out screenOriginX, actualContentWidth, etc
http://www.coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/
Bump - can Anyone at Coronalabs weight in if this is the expected behavior?
Since I didn’t hear back about whether this behavior is expected, I’ve submitted bug case 21988
Much appreciated Brent. Have a good weekend.
As I understood it, contentWidth and contentHeight always report the portrait dimensions of the screen even when using different orientations, so you could roll your own orientation-sensitive values. It appears that actualContent* are the same thing, only in Corona Units instead of pixels. A page describing the difference (as well as orientation handling) is probably a good idea though.
if I start my app in landscape mode it def reports landscape vals for contentWidth/contentHeight so it’s inconsistent if not a bug
I like your page idea … would be great if they showed the diagram from here but pointed out screenOriginX, actualContentWidth, etc
http://www.coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/
Bump - can Anyone at Coronalabs weight in if this is the expected behavior?
Since I didn’t hear back about whether this behavior is expected, I’ve submitted bug case 21988
Much appreciated Brent. Have a good weekend.
I have the same question.
In landscape mode, using build 1137, Kindle Fire 9":
display.contentHeight 320 display.contentWidth 480 display.viewableContentHeight 320 display.viewableContentWidth 480 display.actualContentHeight 512 display.actualContentWidth 320Hi @jflowers45, @hgbrian,
Sorry for the delayed response. The reason you’re seeing these numbers is this: “display.actualContentWidth/Height” always return values relative to a portrait orientation, just like the “display.pixelWidth/Height” properties. So this is by design… nothing unusual here.
Best regards,
Brent
I have the same question.
In landscape mode, using build 1137, Kindle Fire 9":
display.contentHeight 320 display.contentWidth 480 display.viewableContentHeight 320 display.viewableContentWidth 480 display.actualContentHeight 512 display.actualContentWidth 320@Brent, and everyone, I believe there is a bug actually with this API , because depending on the content scale settings in config.lua ***and the actual content of the scene***, display.actualContentWidth/Height get swapped !
So for letterbox scaling mode, actual content will always return values relative to portrait orientation, but for zoomStretch or zoomeEven, it will return values relative to landscape mode (ie actualContentWidth will be larger than height!).
I still don’t have a minimal test case to be able to file a bug report, because in just plain empty example this API behaves as expected, but with some content inside it suddenly starts returns incorrect values in the pattern I wrote above. Since these API are read-only, I don’t think the problem is in my code, looks like there is something conflicting within the display engine.
Hi @nosheet,
I’d like to investigate this further. Would it be possible for you to assemble a quick test case, or tell me exactly how you’re getting the unexpected results? Is the “content” that you put inside just a standard display object? Does its size fit within the content area or extend outside of it?
Thanks,
Brent
Hi @jflowers45, @hgbrian,
Sorry for the delayed response. The reason you’re seeing these numbers is this: “display.actualContentWidth/Height” always return values relative to a portrait orientation, just like the “display.pixelWidth/Height” properties. So this is by design… nothing unusual here.
Best regards,
Brent
@Brent, and everyone, I believe there is a bug actually with this API , because depending on the content scale settings in config.lua ***and the actual content of the scene***, display.actualContentWidth/Height get swapped !
So for letterbox scaling mode, actual content will always return values relative to portrait orientation, but for zoomStretch or zoomeEven, it will return values relative to landscape mode (ie actualContentWidth will be larger than height!).
I still don’t have a minimal test case to be able to file a bug report, because in just plain empty example this API behaves as expected, but with some content inside it suddenly starts returns incorrect values in the pattern I wrote above. Since these API are read-only, I don’t think the problem is in my code, looks like there is something conflicting within the display engine.