Strange behaviour with stroke width

[hasty]

HI folks, I just discovered that if you apply strokeWidth to a newRect, and then set the object’s width equal to its own width, it actually gets wider:

local square = display.newRect(0, 0, 50, 50)
print(square.width)
square.strokeWidth = 5
print(square.width)
square.width = square.width
print(square.width)
square.width = square.width
print(square.width)
square.width = square.width
print(square.width)
square.width = square.width
print(square.width)

--------------------------------------------------------
50
56
62
68
74
80

The increase in size is also greater than the strokeWidth. Is this behaviour a bug or is there a reason for it? It appears to me that for reading the width of the square, the stroke is included, but for setting the width, the value is interpreted as being for the “core”, so to speak, and then the stroke is added on after. Does other software follow this convention, or is it a solar thing?

[hasty]

It now occurs to me that if setting the width were to include the stroke, the question would arise of whether the stroke should keep its absoute magnitude, or change in proportion to the new size. I guess what it comes down to is that there’s no perfect solution but one must settle on something. I’ve come across this with some of my own stuff and it can be quite a pain to make up my mind on which way to go. If anyone has other thoughts on the matter, please do share.

[XeduR]

Like you already said, this is simply an issue about the width including the stroke.

To me, it makes perfect sense that object.width would be equal to the actual width of the object. It would be weird trying to access the width of an object only to find out that it isn’t the actual width of the object. So, at least to me, this approach is the more logical one.

Now, if you do need to figure out the object’s width without the stroke for your own purposes, you can easily figure that out via widthNoStroke = object.width - object.strokeWidth.

[swaj]

I just ran into this exact issue and while I see how one could logically arrive at this behavior, I think it’s problematic as it leads to some very difficult-to-work-around bugs.

The transition library works by reading the current value, so if I try to animate the width/height of a stroked rectangle, it visually “jumps” to a slightly larger size before animating to the destination properly.

Basically, the idea that I can set width to X and then immediately read width and get (X + n) breaks some pretty fundamental expectations, e.g. ones that transition relies on.