Container's bounds not corresponding with its x,y/width,height

[b005t3r]

I just "discovered" this strange behavior and I'm not sure why things work this way.

var quad:Quad = new Quad(30, 10);
var sprite:Sprite = new Sprite();
sprite.addChild(quad);

Now sprite's bounds are (0, 0, 30, 10), its x,y is (0,0) and size (30, 10). So far so good. But if I do this:

quad.x += 100;
quad.y += 50;

sprite's bounds will be (100, 50, 130, 60), but the rest is still the same - x,y is (0,0) and size is (30, 10). It doesn't make much sens, because by looking at sprite's x,y and size you'll get the impression it's positioned in the upper-left, it's 30px wide and 10px high. By looking at it bounds that it's positioned at (100, 50) and it's 30 by 10 px. But none of it is true, because (for me it's the only logical solution) it should be positioned at (0, 0), be 130px wide and 60px high.

Am I missing something? :)

[PrimaryFeather]

It helps to look at the exact definitions of the different properties you're looking at. Granted, those are mostly only existent in my head, so I can understand any confusion: 😜

• The "position" of an object (x & y) describes the location of its coordinate root (!) in the parent coordinate system. When I think of an object, I always have its coordinate axes in my head, with a pin stuck trough the root, attached to the parent.

→ Thus, the position of the quad is given relative to the sprite; and the position of the sprite is given relative to its parent (unknown in that sample).

• The bounds property returns the bounds of an object in its parent's (!) coordinate system.
• The width and height properties are just shortcuts to object.bounds.width and object.bounds.height.

→ The bounds of the sprite will return the width and height of the bounds rectangle, i.e. the width and height of the quad; no matter where that quad is placed.

That's also exactly how the original Flash display tree works, and it makes a lot of sense in terms of consistency. It's always a matter of coordinate systems: as soon as you think in those terms, everything is completely logical.

I hope that helps! :smile:

[b005t3r]

Yes, all of this is clear, but I wasn't taking about Quad's bounds, but the ones of the Sprite. The thing is Sprite is anchored at it's (x, y) inside its parent, BUT its width/height does not change when this Sprite's children change their position - width/height is based on Sprite's children bounding box (which is calculated in Sprite's parent coords), but doesn't take into account where the Sprite is anchored.

I found out about this while porting Starling to Kotlin (for fun :smile:) and fixed it in my port by simply merging the resulting bounds with Sprite's location (which is a point at (0, 0) in Sprite's space). After this fix things make sense to me:

https://github.com/b005t3r/Kotling/blob/master/core/src/main/kotlin/com/kotling/display/Container.kt#L234-L268

I also created some tests for it: https://github.com/b005t3r/Kotling/blob/master/core/src/test/kotlin/com/kotling/display/test/ContainerBoundsTest.kt

PS. I found a different but while playing with this in Starling, its connected to skewX and skewY, but I just create a different issue for it.

edit: Actually, I can't reproduce the other issue right now - I was getting weird results when using a not-optimized version of get transformationMatrix (the one for skewX/skewY not being zeros).

[PrimaryFeather]

Yes, all of this is clear, but I wasn't taking about Quad's bounds, but the ones of the Sprite. The thing is Sprite is anchored at it's (x, y) inside its parent, BUT its width/height does not change when this Sprite's children change their position - width/height is based on Sprite's children bounding box (which is calculated in Sprite's parent coords), but doesn't take into account where the Sprite is anchored.

That's what I meant when I wrote that it depends on the definitions of those properties. By definition, the width of a sprite is just the width of its contents. It's origin has nothing to do with it. For me, this makes sense - but I can understand that others see this differently.

BTW: Kotling? Man, how cool is that?!?! Definitely keep me updated on your progress, and let me know if you run into any other things you find non-intuitive.

[PrimaryFeather]

Nevertheless, I'll close this issue now, since it works as designed, from my point of view. :wink:

[b005t3r]

BTW: Kotling? Man, how cool is that?!?! Definitely keep me updated on your progress, and let me know if you run into any other things you find non-intuitive.

Sure, no problem :)

BTW, I'm still unable to do events, which are like a core mechanism in Starling, in Kotlin, but once the v1.1 is out it should be possible to C#-like events :)

Nevertheless, I'll close this issue now, since it works as designed, from my point of view.

Sure. For me it still is a bit confusing to have size in such abstract form, disconnected from position. I also defined something similar to UIKit Views' internal bounds in my port, so this is one things I had to change.