Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

object.contentHeight returns truncated value
Started by rune7 Mar 02 2019 06:35 AM

8 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

rune7

[GLOBAL: userInfoPane.html]
rune7
  • Contributor

  • 362 posts
  • Corona SDK

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



[TOPIC: post.html]
#2

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 674 posts
  • Corona SDK

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 :D
 



[TOPIC: post.html]
#3

rune7

[GLOBAL: userInfoPane.html]
rune7
  • Contributor

  • 362 posts
  • Corona SDK

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.



[TOPIC: post.html]
#4

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 674 posts
  • Corona SDK

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.



[TOPIC: post.html]
#5

rune7

[GLOBAL: userInfoPane.html]
rune7
  • Contributor

  • 362 posts
  • Corona SDK

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.



[TOPIC: post.html]
#6

XeduR @Spyric

[GLOBAL: userInfoPane.html]
XeduR @Spyric
  • Contributor

  • 674 posts
  • Corona SDK

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? :D 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.



[TOPIC: post.html]
#7

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,317 posts
  • Enterprise

.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)



[TOPIC: post.html]
#8

nick_sherman

[GLOBAL: userInfoPane.html]
nick_sherman
  • Corona Geek

  • 1,744 posts
  • Corona SDK

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.

[TOPIC: post.html]
#9

rune7

[GLOBAL: userInfoPane.html]
rune7
  • Contributor

  • 362 posts
  • Corona SDK

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.




[topic_controls]
[/topic_controls]