UI elements in ScrollingFrames should resize according to AbsoluteSize, not AbsoluteCanvasSize

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too hard to create ScrollingFrames with elements that scale correctly as the CanvasSize is resized.

If Roblox is able to address this issue, it would improve my development experience because it’s a bit of a hassle to get ScrollingFrames to scale its children in a desired manner.

Currently, you have to either:

  1. Use AutomaticCanvasSize, which does not work correctly 100% of the time; I’ve noticed it doesn’t really work well with scaled UILayout objects.
  2. Use scripts to update the CanvasSize of ScrollingFrames automatically as we add/remove objects, as well as the properties of UILayout objects that position/size a ScrollingFrame’s children.

UIAspectRatioConstraints and UISizeConstraints would work to maintain size, but positioning and padding would still have to be accounted for.

Still though, it shouldn’t be any more complicated than just relying on the size being based on AbsoluteSize.

If you think about it, it doesn’t really make any sense that UI objects, who have their size properties scaled, scale according to AbsoluteCanvasSize, and not AbsoluteSize. During runtime, ScrollingFrames will almost certainly have elements that are added or removed from them, so of course, we’re going to have to resize the CanvasSize automatically so it conforms to the size of the contents.

Obviously, it makes total sense that UI objects respect AbsoluteCanvasSize when it comes to positioning them, but when it comes to size, I can’t really see a reason why size is not based on AbsoluteSize.

Let’s say we need more space for more objects in this ScrollingFrame:

image
image755×449 103 KB

The UIGridLayout is scaled:
image

When I resize the CanvasSize, I get this:

image
image759×441 97.4 KB

So, UIGridLayout respects CanvasSize. Why, though? I don’t really see why anybody would want this behavior. It should definitely be based on AbsoluteSize, not AbsoluteCanvasSize. That way, we’d be able to set the size of a UI object or the size and padding components of UILayout objects one time, and never have to worry about it again.

11 Likes
#2

Also something to add, UIGridLayout and UIListLayout are generally forgotten instances (when it comes to their bugs) that don’t have much flexibility and are riddled with bugs all over the place.

Sizes for each element is strictly declared with-in (im assuming) the C++ layer (at least for UIGridLayout), instead of the size being applied (then instances that influence or modify the size entirely have their changes applied right after) then reading the resulting size of the element. This is apparent when the element in question has leading elements, where the positions of the leading elements are set according to what the strictly defined size is by the UIGridLayout CellSize property, not by what is actually visible on screen. This looks increasingly jarring, and make development around these instances more of a headache than they need to be.

However, considering the new Flex update for UIListLayout, which is how things should be, I will probably soon see UIGridLayout being deprecated or as a legacy feature, which addresses exactly said above.

However, UIListLayout also has a recurring problem of sometimes not updating the list of childrens positions until something changes with the parent element, such as the size or position of it.

Something to also recommend, instead of just defaulting behavior to use AbsoluteSize to scale children, have a property within the UIGridLayout, such as ScaleBehavior being an enum of either Enum.ScaleBehavior.AbsoluteSize and Enum.ScaleBehavior.CanvasSize respectively.

4 Likes
#3

Personally I would love this! Its a pretty annoying thing that there isnt a way to do this, it should also probably be toggleable, cause people would complain if it wasnt lol

5 Likes
#4

It’s really hard to scale ScrollingFrames under sophisticated UI hierarchies right now - I’ve had to resort to using complicated scripts to do it automatically. I honestly think engineers want this to be the ideal behavior, but due to ‘backwards compatibility’ and the fact that everyone has moved to rely on this awkward behavior, it’d simply break too many games if it was changed so drastically and hence this is the excuse they tend to fall back on

2 Likes
#5

I can’t even imagine a use-case where you would want it to be relative to the AbsoluteCanvasSize

2 Likes
#6

using scrolling frames makes me wanna cry

3 Likes
#7

Yeah, this is what I was thinking was the reason this isn’t already a thing. But as @veilict said, the introduction of a ScaleBehavior property of ScrollingFrame/UIGridLayout/UIListLayout, which would be set to CanvasSize to default to allow backwards compatibility, would be very useful.

2 Likes