Incorrect `AbsoluteSize` value for `AutomaticSize = XY` container

Bug Reports Engine Bugs
,
#1

In some specific cases, the AbsoluteSize of a parent container will be reported incorrectly when it uses AutomaticSize.

For example, note the AbsoluteSize of this container:

CleanShot 2024-01-22 at 18.28.13@2x
CleanShot 2024-01-22 at 18.28.13@2x742×632 63.2 KB

Now, the AbsoluteSize of a child whose Size property is 2, 2 in scale:

CleanShot 2024-01-22 at 18.29.26@2x
CleanShot 2024-01-22 at 18.29.26@2x774×1342 134 KB

Code sample:

CleanShot 2024-01-22 at 18.31.17@2x
CleanShot 2024-01-22 at 18.31.17@2x1480×1026 247 KB

And here’s a place file to reproduce the bug:

AutomaticSizeRepro.rbxl (58.8 KB)

Expected behavior

The parent container should report its AbsoluteSize as the correct bounds of all its children.

3 Likes
#2

Thanks for the report! We’ll follow up when we have an update for you.

#3

Hi @grilme99 thank you for reporting this issue. Unfortunately AutomaticSize doesn’t support scale based sizing or positioning well (or at all) in most cases. This is a known issue that we’re hoping to address in the future, but we currently don’t have an ETA for when a fix will be available.

#4

Hi @grilme99, I was wondering if you could share more about this usecase? Are some of the child frames a known fixed size, while others are allowed to change their sizes dynamically?

For example, if we look at the simpler case of only the DraggableElement parent with the DraggableElement child, we have this:
image

  • DraggableElement (AutomaticSize=XY)
    • DraggableElement (Position=(0.5,0,0.5,0), Size=(0,100,0,100), AnchorPoint=(0.5,0.5)).

One might expect that the parent DraggableElement’s AbsoluteSize is calculated as 100x100, since that is the size of the child. However, this setup is a little complicated because the child has scale-based position and a non-zero anchor point. Here is a step-by-step explanation of how the parent’s 75x75px size was calculated:

  1. The minimum size of the child frame is calculated as 100x100
  2. The parent’s minimum size is calculated by placing the child at scale position (0.5, 0.5) with the parent having size (0,0) at this point. The child also has anchor point (0.5, 0.5). So the child’s anchor point is positioned at the origin (0.5*0, 0.5*0)=(0,0), and the parent’s minimum size is calculated as the bottom-right most extents of the children, which is 50x50.
  3. Next, the parent can position the child because it’s size is now known (determined as 50x50). So we can position the child’s anchor point at (0.5*50, 0.5*50) = (25, 25), and again it has anchor point (0.5, 0.5). The parent’s final content size is again found from the bottom-right most extents of the children, which is (25,25) + (50,50) = (75,75).

One thing I would recommend is making the child DraggableElement have AnchorPoint=(0,0) and Position=(0,0,0,0). Then, both the parent and child DraggableElements should have size 100x100 as expected.
Would this option work for your usecase?

1 Like
#5

Thank you for the detailed breakdown! I realize now why this is more complex than it seems.

This is for a component called Draggable. It wraps any other UI element and allows it to be moved, resized, and rotated within a drag area. To make the API easy to use, I wanted to use AutomaticSize so that consumers don’t have to pass a size value they might not know.

I’ve now solved this specific use case by using a known size and pre-measuring the elements before wrapping them in a Draggable. It’s not as convenient but is much more stable and reliable.

1 Like