AutomaticSize Studio Beta

The goal

  • Create a resizable Material component, using only UI constraints
  • Resizing requires no further scripting, nor running the game, to function (it’s all handled from within Studio)

This is an elegant way to instantly display changes to the developer, without any plugins needed, and without having to run the game every time. Although many other attributes (such as style) may not instantly take effect, one of the key aspects of UI design to perfect (in my opinion) is composition. If you have an incorrect scaling value, bad positioning, or a wonky padding, it can make your UIs feel cramped and unprofessional in an instant.

Under normal circumstances (assuming everything about the appearance is implemented on the scripting side), the developer would have to playtest their game to see every change they made. If your place is more than a barren baseplate and/or you have slower hardware, you can waste precious seconds of your life waiting for Studio to behave. A normal playtest can take anywhere from 5–10, even 15 seconds to load!

With the addition of AutomaticSize, this finally becomes possible! Right?

However, there’s a problem

So, what went wrong?

This baby relies entirely on AutomaticSize to hold its shape. It kinda works, until you click on it. Things get taboo from there. This is because two main components, namely the shadow and ripple, both extend out of the button’s bounds: The shadow always remains slightly larger than the button’s hitbox, causing the parent to compensate while also off-centering itself. The ripple, using Scale as its sizing mechanism, causes the size to recursively multiply, quickly creating an appendage that pierces through the fabric of spacetime.

Elemental visualization: shadow offset, ripple darkened and unclipped

As it stands, there’s currently no way to exclude these objects from influencing their parents’ size. This was quite unfortunate when I’d found out, as this feature has the potential to be a massive QoL improvement. Seriously! This is a game-changer.

However, I’ve got an idea:

Class : image UIAutomaticSize

Inherited from: Instance

Instead of AutomaticSize being a property of GuiObject, why not turn it into a UI constraint? This has a couple added benefits, such as:


UI constraints are physical objects in the game hierarchy. This makes them more hands-on; easier to work with. Instead of scrolling through every property of a GuiObject, you can quickly spot a stray UIAutomaticSize in your explorer.


Instead of adding several properties to the GuiObject class, you can instead add properties to the UIAutomaticSize. This allows for an acceptable way to fine-tune your automatic sizing. A few examples of such properties include:

bool Recursive

Whether children of children should influence the size of the parent, or in other words, whether the bounding box of each child will respect their descendants or not. Small performance benefit most of the time, but could massively help when (potentially) thousands of GUIs are parented to an automatically-sized object.

bool IgnoreScale

When true, any children using Scale as their sizing method will not influence the final size, and instead will use the final size to determine their own size proportionally. Helps defend against the recursive nature of using it.

AutomaticSize AutomaticSizingMode

The AutomaticSize enumeration used for GuiObjects, functionality doesn’t change.


The most critical part. As you may or may not know, you can use folders to blacklist certain objects from the effects of a UI constraint, as shown here:

Intentional or not, this is a handy quirk that allows one to hide certain objects while (generally) keeping the hierarchy intact. GUIs parented to folders are still influenced by the folder’s parent as you would expect, but are not influenced by UI constraints.

This quirk alone would solve both of my problems: I could simply parent my ripple + shadow to its own folder, then the constraint would treat it like it wasn’t there. This would preserve the physical bounding box of my button, while allowing for things to exceed it visually.

Overall, I’m very pleased with this feature. At the very least, I no longer need TextService to automatically size my TextLabels, which in itself is a massive step in the right direction. Anything not too complex can easily find a way to use AutomaticSize, which is what I love about it.

However, for those who want to go above and beyond, or generally want to use (and abuse) this feature to the fullest extent possible, it lacks the very fundamental capability of ignoring certain objects. I hope this can be resolved one way or another, and I seriously look forward to using this feature as a daily driver in my UI-designing extravaganza.



Been having nothing but issues with this feature. It just… doesn’t scale UI elements properly. Especially text.

Most recent example. As you can see, the bounds just do NOT fit the text.

Also having this issue. A lot. Text will just be completely scrunched up and unreadable. Happens a good 20% of the time.


is it working now, Is it under maintenance?

Hi @ee0w - thank you for the detailed feedback and the suggestion! I’ve heard several suggestions from devs to introduce a size constraint that, when parented to a GuiObject, will be omitted from AutomaticSize calculations. Do you think something like that might help with your use case?

Hi @BuildIntoGames - would you be able to recreate this issue in a place file and attach?

Hi @virtuaLsc - the feature has some known issues associated with it that are actively being resolved. The known issues are listed here, however, some new issues have been reported since that list was created:

I’ll look into starting a new thread or perhaps updating the original thread.

Everything was very good, as in the video I shared above.
But today I realized that this is not working.
it does not automatically grow when a new post arrives.
I am fixing the problem by turning the ClipsDescendants feature in textlabel on and off.
I’m sorry for my bad english.

1 Like


Happened here also. There’s some weird UI scaling and I literally have no idea why, because sometimes it’ll work on those devices, and sometimes it won’t.

1 Like

ScrollingFrame AutomaticCanvasSize

When the nested ScrollingFrame(Darker one) has ClipsDescendants activated, the Parent’s AutomaticCanvasSize still recognizes the CanvasSize to not be clipped, but it should recognize the nested ScrollingFrame’s AbsoluteSize, not CanvasSize.

As shown above, when I set ClipsDescendants to true, nothing happens, but the Parent ScrollingFrame’s CanvasSize should fit to the size of the nested ScrollingFrame


Hi @virtuaLsc - if you can attach a place file that reproduces the issue, that would be great!

1 Like

Hi @noot20000 - thank you for the bug report and for the video demonstrating the issue. This is an issue where AutomaticSize is incorrectly taking the canvas size of the scrolling frame into account rather than the ScrollingFrame’s Size property. I’m working on a fix for this right now - if you have time to attach a place file, I can verify whether the fix I have will resolve the issue (I believe it will, but good to double check).

Thanks for the bug report!

1 Like

Hi @BoxBloxes - there are a few reported issues of UIScale not working properly with ScrollingFrame. If you have time to create a place file that reproduces this issue, that would be great!


1 Like

I found that when using UIPadding with a frame that has automatic size, it does something weird the first time I open the UI. As soon as I interact with it though, it gets back to normal.

The only way I found to go around this bug is to use create my own paddings and not use the UIPadding Property.


Having issues with this feature. With TextLabels, I can’t get the AutomaticSize to work as expected; it either remains the same size or becomes extremely wide (much longer than the actual text’s length).

I’m also having trouble getting it to work as expected in this situation. I select the descendants of the Frame I want to have AutomaticSize X on at the start to show their total size. Then I toggle AutomaticSize on & off near the end of the video. As you can see, it extends far past the boundaries of the actual contents.

It seems like UIListLayout breaks the property somehow, making it think that its contents are much larger than they actually are.

EDIT: Here’s a link to the bug report, with a repro .rbxm file: (AutomaticSize Beta) Sizing error with UIListLayout/TextLabels


Hi @gui110 - we’ve noticed a few issues similar to this where the layout state isn’t updating until interaction occurs. We’ll get this resolved! Thank you for the bug report, and for your patience.


Hi @Polyhex - responded in the other thread you posted. Thanks!

1 Like

Ideally, I wish this could be extended to all UI constraints, with a toggle for each, so I wouldn’t have to work off of a hacky solution using folders. But really, anything to just blacklist AutomaticSize would seal the deal.

With AutomaticCanvasSize enabled is there a known way of getting the CanvasSize of the Scrolling Frame? When enabled it sets the CanvasSize property to {0,0},{0,0}, and I don’t want to find the CanvasSize using math when its already being computed. There is a AbsoluteCanvasSize property, but it is locked and only useable by CoreScripts, which is a shame.

Hi @gui110 , we have recently deployed a related fix, you can probably try updating and verifying if that resolves your issue. Please let us know if you have any questions or updates. Thanks!


Hi hi,

I’ve noticed an issue with AutomaticSize which may(???) be related to using a UIListLayout inside a frame that’s being automatically resized. I say may as the difference between the expected and actual size gets larger as more GuiObjects are added to the frame, as though there was some kind of padding issue.

Here’s an image of the issue, the red outlines are UIStroke’s parented to the AutomaticSize Y Frame:


I’ll attach a placefile with some UI that’s having the issue.
automaticsize_issue.rbxl (40.6 KB)


1 Like