Reproduction Steps
This issue occurs when a UIScale constraint is placed within a Frame, in which a ScrollingFrame occurs (the scrolling frame contains a UIListLayout of text items, however on brief test it also works when no UIListLayout constraint is used). This occurs in both studio and client.
System Information: Windows 10 Desktop, AMD A10-5700, 16GB RAM, NVIDIA GeForce GT 1030
Expected Behavior
I expect the CanvasSize to automatically match the contents of the scrolling frame, such that the bottom of the last item is the maximum scroll distance of the frame, as per when UIScale = 1.
Actual Behavior
When UIScale > 1, the bounds are less than the scaled contents of the frame, so at the maximum scroll distance it hasn’t yet shown all the elements.
(if you set UIScale < 1 there also seems to be an issue with the contents jumping once the scrollbar reaches a certain distance.)
Workaround
Programmatically getting the AbsoluteContentSize of the UIListLayout, dividing this by the scale and setting that to the CanvasSize with AutomaticCanvasSize set to None, however I’m struggling to get this workaround to work with a more complex scenario.
Issue Area: Engine Issue Type: Display Impact: Moderate Frequency: Constantly Date First Experienced: 2021-07-07 00:07:00 (+01:00) Date Last Experienced: 2021-07-07 00:07:00 (+01:00)
I can second this report. I frequently work with UIScale, and AutomaticSize seems to be messing up things like text labels, lists, and grids if the UIScale affecting the automatic sized frame is not equal to 1.
This is causing major issues in my game with users on mobile or on monitors with resolutions >1080p (due to the math I am using). It will be a pain to switch every instance of automatic scaling to use custom math, and I really hope this is fixed soon.
To work around the problem, I’ve been using UIListLayout.AbsoluteContentSize when possible - but I shouldn’t have to do this and it’s been a real pain point in my UI development! Really hoping for a fix.
Hey, so when I apply padding to my UI listlayout the automatic canvas size doesn’t size correctly on the y axis. And it gets worse as I increase the padding. It wont let me scroll down more than this which doessnt show the whole UI. This is a major problem because I have to resort to custom code just to get it to work using a UI listlayout. I am able to reproduce this problem 100 percent of the time.
Is there any update on this , it seems the automatic canvas size is wrong for items in a grid or list layout that have padding applied , additionally applying ui padding to the bottom has no effect on the automatic canvas size
UIPadding, UIScale, and UIAspectRatioConstraint all cause issues with automatic canvas sizing. It would be nice to get a response from @CharlieGordonnn or another staff assigned to this issue since this is frustrating to deal with during UI design.
Hi @bmcqqq@baddiecoder , thank you for bringing this to our attention. We’ll prioritize the issue in our backlog and conduct a prompt investigation. Your patience is greatly appreciated!
Hi @MrNicNac , we are working on fixing the issue you reported in this thread, which seems to be a different issue than the original post. Hopefully we will have the change submitted soon. Thanks for your patience!
Hello, I’m experiencing a similar issue with ScrollingFrames AutomaticCanvasSize being inaccurate due to Padding of UIListLayout (at least I’m assuming that’s what’s causing the issue)
Basically it prevents the bottom (12th out of 12) item from appearing in the list at all
Hi @Moduluous , thanks for sharing the repro file. Unfortunately, there is a known issue where AutomaticSize does not work well with children with scaled sizes in it. For example, in this case, the textLabel has 0.1 scaled size on Y axis which will be resolved as 0.1 * ParentSize, since there are 12 of them, the ParentSizewill be resolved as 12 * 0.1 * ParentSize = 1.2 * ParentSize, which will as a result making the scaled children larger. In a word, the children have sizes that depend on the parent, and the AutomaticSized parent has its size depending on children, which will be an infinite lock that prevents from the sizes from being resolved correctly. To work around this, we suggest using fixed offset sizes for children that are independent from the parent and also a fixed offset size for the list layout padding. Sorry about the inconvenience.
