local rect = display.newRect( 100, 100, 50, 51.99 ) print( "contentHeight: ".. rect.contentHeight, "Height: ", rect.height ) Result: contentHeight: 51 Height: 51.990001678467
Build3459. Why do I get 51 instead of the actual height??? This seems like a bug
You get 51 because pixels are the smallest unit that can be displayed on a screen and therefore they can only be represented by integers, and instead of rounding the pixel values, Corona simply floors them.
Math & reality lesson:
This is really the same as with counting humans. If you have 100 people employed by a company and you expect the company’s number of employees to rise by 2% every year, then after the first year the number of employees would grow by 2. The year after that by 2.4. It’d be safe to expect that since we are talking about humans, the growth would again be 2 instead of 2 whole humans and a severed torso.
I’ll show myself (and my dumb examples) out 
XeduR @Spyric,
That’s a nice analogy but completely wrong. height and contentHeight do not need to be whole numbers. nor do they represent actual pixels according to the docs. They represent an object pr group height in content space. They should be similar in case no rotation or scaling has been applied.
They don’t have to be inserted as integers, sure, but that’s the only way that Corona will draw the display objects.
Try creating a rectangle with a non-integer width or height and you’ll find that the display object’s width and height are always integers. As you don’t believe this, take a screenshot of the simulator and check it out in your image editing software. Fractions of pixels are simply impossible to represent on standard screens.
I don’t remember if Corona rounds the values or applies math.floor or math.ceil to them when it creates the display objects, but in the case of that object’s contentHeight, it seems to use math.floor.
That is not the question and its also wrong as corona scale content values to real device values according to the device resolution.
The question is why height is different to content height in contrast to the docs.
Not the question, true, but you can personally check whether what you’ve encountered is a bug or not based on what I’ve said.
And still, what on Earth do you think is wrong about what I’ve said? Corona’s scaling affects the width and height of display objects, sure, but those scales values are still subject to the same rules I’ve mentioned. Prove me wrong.
.width and .height (the actual dimensions of the “theoretical” rectangle) may be fractional. they’re rendered via opengl as actual geometry, and may be properly scaled by any arbitrary amount.
of course, when opengl actually rasterizes, then they are limited to actual device pixels, but internal storage doesn’t “discard” the fractional dimensions (ie, it’s merely a rendering artifact). so asking for the actual width or height will return the actual width or height.
otoh .contentHeight (along with all related min/max values of .contentBounds) have always been returned as integers. the reason is unclear, but perhaps they’re used in that form for “performance”, perhaps during culling? (pure wild speculation, haven’t checked the source on that)
one could argue that returning fractional content coordinates would be preferable (for example: mouse event coords used to be similarly truncated, but that was changed, and now return fractional content coords, providing far more “accuracy” at low content dimensions on a high-resolution device – search forums for very old posts, it was a real problem)
I deleted my previous post but after thinking about it, it’s still valid. ContentWidth is a value in content co-ordinates, not pixels. It should surely be the same as Width, unless xScale or a rotation has been applied.
Hi,
I find it weird that contentWidth is integer based, if that was even the intention. It means you can not rely on its value for accurate positioning unless you truncate your computations in a similar way.
About a year into developing with Corona I “discovered” contentWidht/contentHeight and happily switched over since it reduced code clatter when you need to programmatically place objects in a scene. I may have never noticed that it uses whole numbers since in all our apps so far, we never needed refined placement. Until now that is. In our newest app, we want to have HUD elements precisely placed and in such scenario using contentWidth/Height results in either overlaps or gaps between elements depending on the device used for testing.
Its a relatively easy fix to go back to height/width but its a bit of an overhead since now I need to manually consider the object scale and rotation when positioning.
Anyway, its important to note in the docs this important difference between the methods so that people will know which to use depending on their needs.
You get 51 because pixels are the smallest unit that can be displayed on a screen and therefore they can only be represented by integers, and instead of rounding the pixel values, Corona simply floors them.
Math & reality lesson:
This is really the same as with counting humans. If you have 100 people employed by a company and you expect the company’s number of employees to rise by 2% every year, then after the first year the number of employees would grow by 2. The year after that by 2.4. It’d be safe to expect that since we are talking about humans, the growth would again be 2 instead of 2 whole humans and a severed torso.
I’ll show myself (and my dumb examples) out
XeduR @Spyric,
That’s a nice analogy but completely wrong. height and contentHeight do not need to be whole numbers. nor do they represent actual pixels according to the docs. They represent an object pr group height in content space. They should be similar in case no rotation or scaling has been applied.
They don’t have to be inserted as integers, sure, but that’s the only way that Corona will draw the display objects.
Try creating a rectangle with a non-integer width or height and you’ll find that the display object’s width and height are always integers. As you don’t believe this, take a screenshot of the simulator and check it out in your image editing software. Fractions of pixels are simply impossible to represent on standard screens.
I don’t remember if Corona rounds the values or applies math.floor or math.ceil to them when it creates the display objects, but in the case of that object’s contentHeight, it seems to use math.floor.
That is not the question and its also wrong as corona scale content values to real device values according to the device resolution.
The question is why height is different to content height in contrast to the docs.
Not the question, true, but you can personally check whether what you’ve encountered is a bug or not based on what I’ve said.
And still, what on Earth do you think is wrong about what I’ve said? Corona’s scaling affects the width and height of display objects, sure, but those scales values are still subject to the same rules I’ve mentioned. Prove me wrong.
.width and .height (the actual dimensions of the “theoretical” rectangle) may be fractional. they’re rendered via opengl as actual geometry, and may be properly scaled by any arbitrary amount.
of course, when opengl actually rasterizes, then they are limited to actual device pixels, but internal storage doesn’t “discard” the fractional dimensions (ie, it’s merely a rendering artifact). so asking for the actual width or height will return the actual width or height.
otoh .contentHeight (along with all related min/max values of .contentBounds) have always been returned as integers. the reason is unclear, but perhaps they’re used in that form for “performance”, perhaps during culling? (pure wild speculation, haven’t checked the source on that)
one could argue that returning fractional content coordinates would be preferable (for example: mouse event coords used to be similarly truncated, but that was changed, and now return fractional content coords, providing far more “accuracy” at low content dimensions on a high-resolution device – search forums for very old posts, it was a real problem)
I deleted my previous post but after thinking about it, it’s still valid. ContentWidth is a value in content co-ordinates, not pixels. It should surely be the same as Width, unless xScale or a rotation has been applied.
Hi,
I find it weird that contentWidth is integer based, if that was even the intention. It means you can not rely on its value for accurate positioning unless you truncate your computations in a similar way.
About a year into developing with Corona I “discovered” contentWidht/contentHeight and happily switched over since it reduced code clatter when you need to programmatically place objects in a scene. I may have never noticed that it uses whole numbers since in all our apps so far, we never needed refined placement. Until now that is. In our newest app, we want to have HUD elements precisely placed and in such scenario using contentWidth/Height results in either overlaps or gaps between elements depending on the device used for testing.
Its a relatively easy fix to go back to height/width but its a bit of an overhead since now I need to manually consider the object scale and rotation when positioning.
Anyway, its important to note in the docs this important difference between the methods so that people will know which to use depending on their needs.