This is quite helpful for Everyone!
I guess one of the main reasons for adding this feature is for auto-translated games because of the size of the text that is different in other languages.
Great job!
I just hope Roblox will be able to finish this yearās Roadmap.
More info on this would be great. Can you send me a test place where you can repro the issue?
I already sent it in the studio bug topic.
This is a great feature to add! Regardless of most people probably using this feature for a more basic use, I canāt wait to see what people come up with, I can see a lot of creative features like buttons and loading screens using this feature!
For example, thisād make a great loading screen 
This means I wonāt need to update the size of my UI objects every time they changeā¦ Thank you very much for this!
This is quite useful even if I donāt tend to script, however, Iād like to know what other type of frames will be support to AutomaticSize such as ScrollingFrame, other than that I donāt see any massive issues and hope you keep up the good work since Iām super excited for a planned release of realistic clouds.
Hey @rogchamp - yes thatās correct. In the case of the parent frame set to automatically, size, it will size itself to fit the content of the children, in this case whatever the size of the TextLabel is. You can set AutomaticSize on both the Frame and the child TextLabel if youād like both the parent Frame and the TextLabel to fit the text.
Thank you for trying out the beta, and for your feedback! 
Hi @IAmPinleon - TextScaled will change the font size to fit the available space of the size of the TextLabel. Without AutomaticSize, the TextLabel size is technically fixed.
The pipeline for TextScaled/AutomaticSize is something like this:
Thank you for trying out the beta!
I am in awe. This is exactly what I needed for my game. I have some reference images here of what Iām working on. Anything with the red background is using the AutomaticSize feature, everything to the right is hacked together using Scale values.
This one, the example display is at 1280x720:
1366x768:
1920x1080:
Serious props to the team and people who worked on the AutomaticSize feature, because this is a lifesaver. Iām super excited and canāt wait for this to get out of beta.
Hi @iiau - so when Automatic Size resizes the object from sizeOld to sizeNew (for example), give the ability to specify a Tween property that determines how the resizing occurs visually? Is that correct?
Hi @TheCarbyneUniverse - I created a ticket to investigate the inset issue you described. As @FilteredDev mentioned, the Size property is indeed unaffected by AutomaticSize. The actual size bounds should be read from AbsoluteSize.
As far as min size goes (speaking of the Size property), the Size property is supposed to act as a āminā bounds for AutomaticSize, although Iāve seen cases where that isnāt happening, so Iāll write up a ticket for that as well. The idea is that the parentās Size acts as a āmaxā and Size acts as a āminā.
Thanks for trying out the beta and sharing your feedback!
Hi @Lulu_5239 - there is a new property for ScrollingFrame called AutomaticCanvasSize, which is intended to automatically resize the CanvasSize based on the contents of the ScrollingFrame. There is a bug with this feature currently, but weāre working on a fix.
Thanks for your feedback!
Hi @rogeriodec_games - thank you for sharing this bug report! I replied in your other post as well, but Iāve created a ticket to investigate this behavior.
Thanks for trying out the beta!
Hi @Codesense - yes we should have the ScrollingFrame issue resolved soon. Thanks for trying out the beta and for sharing your feedback!
If you want to share more details about the issue with tweening, thatād be great!
Hi @M_antas - all GuiObjects have the AutomaticSize property, included ScrollingFrame! The Frame objects used above were just an example.
Although ScrollFrame itself can use the AutomaticSize property, itās more useful to use its AutomaticCanvasSize property, which will automatically resize CanvasSize to fit child contents. Thereās an issue with this functionality which should be resolved soon.
Thank you for your interest in the beta, and for your feedback!
IS THAT AUTOMATIC SIZE I SEE HNNNNNNNNNNNNNNNNG NO WAYYYYYYYYYYYYYYYYYYY
i am.
so so . so os oso . so so so. excited for this. this is extremely useful for resizing containers with an arbitrary content size. as a matter of fact, this would make creating cooler chat systems magnitudes easier than how it is now. i think.
but no seriously this is actually really poggers and i appreciate this and i appreciate you, guis are finally getting the love they deserve!!
Yes please, this is exactly what we want! What would also be appreciated are two additional properties:
Final tween time is calculated like so:
Time = (TimePerPixel * PixelDelta) + TimeOffset
You should also consider doing the tweens seperately; one tween for the X axis, and one for the Y, so that if you expand the X field by 200 and the Y by 20 at the same time, then the Y takes less time than the X (as it has less distance to travel).
There are two issues I have encountered with the beta feature.
They both seem to be related to:
The expected behavior would be that they function the same out of the box.
OS: Win10
Simple Tween
AutomaticSize_TweenRepro.rbxl (22.7 KB)
The frame successfully loops back and forth across the screen when the beta is disabled or the frame is a direct descendant of the ScreenGui.
The tween is unsuccessful when the beta is enabled, and the frame is not a direct descendant of the ScreenGui.
SurfaceGui
AutomaticSize_SurfaceGuiRepro.rbxl (23.6 KB)
If instance(s) are created every render frame, subsequently deleted the next, and none are a direct child of the SurfaceGui, then they do not render. They do however render after selecting the container in the explorer.
Hi @Nabfam - thank you for the suggestion!
One thing Iāve been thinking about with controlling tweens for resizing is the following case: letās say you have a parent Frame whose AutomaticSize is XY, and has a size of 100x100. Then, you add a child Frame that is 200x200. So the parent frame will need to tween from 100x100 to 200x200.
One issue is that the child Frame will display immediately while the parent Frameās tween will slowly catch up. So, for as long as the tween takes to execute, the child content will be overflow the parent bounds (visually at least).
I suppose you could set the child content initially as transparent, and when the tween completes, remove the trasnparency?
Thanks for checkout the beta and for your feedback!
Hi @UFAIL2 - Iām currently working on a fix that I believe should fix the āsimple tweenā issue. Iāll file a ticket to investigate the SurfaceGui issue as well.
Thanks for reporting this issue and for trying out the beta!
