UIScale causes weird behaviour with UILayout AbsoluteContentSize properties

Reproduction Steps
If you use the AbsoluteContentSize property of a UIListLayout or UIGridLayout instance, when it’s a descendant of anything that uses a UIScale, it will be incorrectly multiplied by the UIScale's Scale.

An example of an issue this causes, is if I use UIListLayout.AbsoluteContentSize to size a ScrollingFrame.CanvasSize - without a UIScale - this works perfectly fine. With one, it (naively?) multiplies the content size by the scale. This leads to the content size being incorrectly larger than it actually is.


repro.rbxl

In the repro place file above, the left GUI is using a UIScale and a scrolling frame which sizes based on the UIListLayout.AbsoluteContentSize. As you can see, it overflows by quite a bit.

The right GUI is where I applied the fix of dividing the UIScale.Scale from the AbsoluteContentSize. It ends up correctly setting the canvas size to the actual content size.

Expected Behavior
AbsoluteContentSize in UIListLayout and UIGridLayout when a UIScale is involved should have the correct size (aka, not multiplied)

Actual Behavior
AbsoluteContentSize in UIListLayout and UIGridLayout when a UIScale is involved has been multiplied by the scale.

RobloxStudioBeta_qHxrDErzO8

Workaround
When grabbing AbsoluteContentSize from UIListLayout or UIGridLayout, have to grab the UIScale in the tree that’s affecting the layout object, and divide the Scale property from the resulting AbsoluteContentSize.

Issue Area: Engine* (please feel free to move this, idk how it ended up in Studio)
Issue Type: Display
Impact: Moderate
Frequency: Constantly

6 Likes

Hello! Thanks for the report. Filed an internal ticket.

3 Likes

Are there any updates to this? I’m still having issues and have been for a while now.

Hi @Vorlias @detourious , the AbsoluteSize and AbsoluteContentSize is expected to consider UIScale while the Size or the CanvasSize is original without UIScale applied, which is as designed. I would suggest using AutomaticCanvasSize.Y for your use case, please let us know if you have any further question. Thank you!

1 Like

Hello, not OP but I’ve been having the same issue - opening their repro place and setting AutomaticCanvasSize to Y does not fix the issue:
image

My usecase, as I believe is many others too, is using UIScale as a tool to seamlessly fit UI elements onto any screen resolution - and this workflow becomes impeded, requiring cumbersome manual workarounds to fix with UIScale.

Thanks for your feedback! When I opened the repro file, the script is setting the canvas size consistently. The canvas size on Y axis is considered a minimum size for the AutomaticCanvasSize. If you set the CanvasSize to be 0 manually (or disable the script from updating CanvasSize) on Y axis and set AutomaticCanvasSize to Y, do you still see the extra space rendering?

You could try replacing the script under StarterPlayer>StarterPlayerScripts>TS>Components>ScrollingFrameComponent.lua with the attached one, where I have got rid of the size calculation and size change signal connection, but only used AutomaticCanvasSize with the CanvasSize.Y initialized to 0:
ScrollingFrameComponent.lua (4.5 KB)
Please let me know if this does not seem to work. Thank you!

Also cc @Vorlias

It seems like these have all been fixed! I’ve had similar issues with e.g. UIScale not working with TextLabels that have had AutomaticSize set on them, but that was quite a while back and it seems to have also been fixed since :smile:

The behavior you described with CanvasSize & AutomaticCanvasSize makes sense; setting CanvasSize to 0 did fix the issue.

1 Like