AutomaticSize Studio Beta

Updates Announcements
#63

Hi all - quick update! The following fixes are now live in v458:

  1. ScrollingFrame’s AutomaticCanvasSize property now working.
  2. Fixed an issue where UIListLayout with AutomaticSize and UIAspectRatioConstraint constrains the object size smaller than it should be. Reported by @blobbyblob.
  3. Fixed an issue where UI objects marked dirty weren’t getting updated properly (this was the source of several reported bugs). Reported by @UFAIL2 (and others!).

For the v459 fixes, I don’t have any updates on when those fixes will be available.

Thanks for your patience with the beta and helping improve Roblox!

2 Likes
#64

I’m having a strange and complicated issue using AutomaticSize that doesn’t seem to be listed in the known issues. Bear with me while I try to explain it, because it’s a doozy. The issue is as follows:

The Setup

I have a UIListLayout that is positioning two elements: a TextLabel and an ImageLabel. In the hierarchy, it looks like this:

image

I have the TextLabel set to be positioned to the left of the image such that this is the result:

image

The Problem

Now here’s where the problem arises. I want the text to scale properly with screen resolution, so I enable TextScaled. However, I also want to ensure that the icon is displayed immediately to the right of the text with no unnecessary space between them besides the UIListLayout padding.

Quick example of what would be unnecessary space:
image

To get rid of any unnecessary space, I should be able to set the AutomaticSize property of the text to “X” and let Roblox work its magic for me. However, this does not fix the issue. At a 1280x720 screen resolution, the bounds of the text with TextScaled enabled should be 72x12, which means the expected width of the label itself, with AutomaticSize enabled, should be 72px as well. For some reason, however, this is not the case and the width ends up at 88px.
image

So let’s dig a little deeper: What happens with TextScaled set to false? Well, the text itself doesn’t scale, but AutomaticSize is calculated properly.
image

But wait, here’s where things get extremely whacky. Upon setting TextScaled to true, the TextBounds property of the label reads the correct size 72x12, with the label’s size being set to 88x12.
image
image

However, upon toggling the “Visible” property of the label to false, then back to true, the TextBounds property will mysteriously update to read “88x15”, without the size of the label actually changing at all.
image
image

Now I’m just spitballing here, but something tells me that the automatic size system and the text scaling system each have their own idea of what the actual size of the text (or the text label) is. I say this because the 88px width that Roblox thinks the text is being displayed at would actually be correct if the AutomaticSize was set to XY and not just X, as seen here:
image

So yeah, this has been an extremely frustrating bug to deal with (and even explain) and I hope it can be fixed soon!

2 Likes
#65

I’m running into a bug using AutomaticCanvasSize with a UIScale. It seems that as you scale down a UI the canvas size slowly starts to go off.

Here is the repro file:
AutomaticCanvasSizeBugRepro.rbxm (11.3 KB)

3 Likes
#66

Hi @Rocky28447 - thanks for the report! Some fixes just went live about an hour ago (updating this forum post now). Can you try re-launching Studio and seeing if the issue is resolved for you? If not, would you mind attaching a place file that shows the issue?

Thanks again!

3 Likes
#67

Hi @grilme99! Thanks for reporting this issue and for trying out the beta. Some fixes just went live (with v459), would you mind restarting Studio and verify if the issue still occurs?

Thanks!

2 Likes
#68

Hi all! Another quick update on Automatic Size:

Release Date
January 2021

Fixes: v459

The following fixes are live in v459 of Studio:

  1. Resolved a bug that was impacting performance (even for GuiObjects not automatically sized).
  2. Resolved an issue where padding of automatically sized hierarchies wasn’t properly accounted for. Reported by @rogeriodec_games.
  3. Resolved an issue with UIGridLayout and UIAspectRatioConstraint where frames were being sized smaller than they should.
  4. Fixed a couple issues with automatic size and rich text where available space of an automatically sized object wasn’t being used correctly and sizing events were improperly queued.
  5. Resolved an issue with UIListLayout and scaled padding for automatically sized elements.
  6. Fixed an issue where a GuiObject with automatic size could be sized smaller than the GuiObject’s own Size property (the Size property acts as a ‘min’ for automatic size).

Known issues (updated)

Please be aware of these issues, however they will not block the release of automatic size:

  1. ScrollingFrame’s with AutomaticSize and AutomaticCanvasSize may overflow their parent bounds.
  2. Improper positioning of automatically sized GuiObjects with inset and middle borders. Reported by @TheCarbyneUniverse .
  3. Other minor performance issues are being investigated.
  4. Scaled children sizes (with scaling > 1) of automatically-sized parents scale based on parent’s updated/automatic size rather than original size (double-accounting for automatic size).
  5. Scaled children positions of ScrollingFrame’s with AutomaticCanvasSize may not automatically resize canvas size properly.

There aren’t any major issues blocking Automatic Size’s release at this point, but we had to delay due to reasons beyond our control. We really appreciate your patience, feedback, and participation in the beta.

Thanks everyone and please stay safe out there!

4 Likes
#69

My apologies, I had intended to include a repro file in my original reply! Regardless, I’ve just restarted studio and tested this again, and I’m now seeing the behavior I’d expect. The text is now being displayed at the correct size for the height of the TextLabel and the X size of the label is being properly sized to accommodate.

#70

Hi @Rocky28447 - awesome! Thanks so much for confirming the issue is resolved :smile:

3 Likes
#71

This is a really nice feature and makes some of my UI development so much easier, thank you!

I was just wondering, is it possible to expose the size that would be set if AutomaticSize was enabled in a read only property (similar to AbsoluteContentSize for the UI Layouts)?

My use case for this would be that I want to animate in a frame by making it “grow” in size from 0,0 at the centre - this can’t currently be done since AutomaticSize would override it! I would then be able to use this property to determine the size that the frame should grow to, and use that in my animation.

I also saw earlier in the thread about someone suggesting the ability to set an Animate property? I think exposing a property and letting us decide our own animation to apply in our code would make it much more flexible (but both these suggestions don’t necessarily need to be mutually exclusive!)

2 Likes
#72

Hi @JohnnyMorganz - that’s a great suggestion! It would be handy to obtain automatically-sized dimensions without having AutomaticSize explicitly enabled. I’ll add it to our list of enhancements to consider for Automatic Size.

Thanks for your feedback and participation in the beta!

3 Likes
#73

I used this a lot during studio! I can’t wait for it getting released.

1 Like
#74

Looks like I was slightly wrong about the issue being totally fixed! I’ve started encountering what I believe to be the same bug but in a different situation from before. I think AutomaticSize does not properly account for UIPadding when calculating the size of automatically scaled text.

Here is a simple repro file. You’ll notice the text is again being drawn smaller than AutomaticSize thinks it is and thus sizes the label too large. The problematic TextLabel is called “Subtitle”.
AutomaticSizeBugRepro.rbxl (25.4 KB)

EDIT: Hey, looks like I’m on a roll! Found another weird bug with AutomaticSize when elements are positioned past the bounds of their parent element. I don’t have the faintest idea why it happens. Here is a repro:
AutomaticSizeBugRepro2.rbxl (27.4 KB)

1 Like
#75

I have a usecase of Automatic Size where I have a “Holder” frame (not using Automatic Size), and inside I have a UIListLayout, filling Horizontally and UIPadding. Within this Holder frame, I have several children (eg. think TextLabels) which are currently have AutomaticSize set to X (so for TextLabels, it would size to the text).

I wanted to have a final frame inside of here, with AutomaticSize set to X which would take up the “remainder of the space available” inside of this Holder frame, without overflowing.

From the OP, it says:

Controlling AutomaticSize Behavior

In addition to the enum property values mentioned above, the behavior of an automatically-sized element is indirectly controlled by the size of it’s parent GuiObject. The size of the parent GuiObject determines the maximum extents that an automatically-sized element can resize up to.

For example, a TextLabel whose AutomaticSize is set to ‘XY’ and is parented to a 200x100 Frame will resize up to 200x100, but no larger.

Currently, the UI does follow this, but because the maximum size used is the size of the Parent Frame, rather than the size of the “remaining space available”, it would overflow. I was wondering if this is something AutomaticSize could support - by instead setting the maximum bounds to space available?

3 Likes
#76

I seemed to have found an issue where AutomaticSize doesn’t respect clips descendants of an underlying ScrollingFrame.

I have a Holder frame, with AutomaticSize set to AutomaticSize.Y,
inside of this Holder frame, I have a ScrollingFrame with AutomaticCanvasSize set to Y and ClipsDescendants set to true
As I add elements inside of the ScrollingFrame, if they start overflowing the current ScrollingFrame bounds, the CanvasSize is correctly increased, but it also increases the size of the Holder frame.

Heres a sample ScreenGui showing the problem:
automaticsize_bug.rbxm (6.8 KB)

If you continue adding more elements inside of the ScrollingFrame, you will notice the Holder frame increases in vertical size

1 Like
Automatic Size Property: Now Available
#77

Hi @Rocky28447 - thank you for the report! I’ll investigate these issues. Thank you for participating in the beta!

2 Likes
#78

Hi @JohnnyMorganz,

The final frame that you mention - the one that you want to fill with remaining available space - would it have child content? Or is the idea that the “filler” frame would simply use up whatever remaining space is available (regardless of its child content)?

That’s an interesting idea. Currently automatic size determines a min and max size and sizes to ‘fit’ the child content by using the min size. It sounds like you would want an ability to toggle the opposite behavior: instead of trying to fit the content (using min size), add the ability to change this behavior to prefer fitting to max size instead. Is that correct?

And then the other change would be this: changing ‘max size’ to be ‘remaining available space’ rather than simply the maximum size of the parent bounds.

Is that an accurate summary of your feedback? Just want to make sure I understand your use case.

Thanks for participating in the beta, and for your feedback!

3 Likes
#79

Hi @JohnnyMorganz - there is an issue with automatically sized ScrollingFrame’s that also have automatic canvas size set. It sounds like this might be a related issue where an automatically sized parent of an automatic canvas size ScrollingFrame is causing erroneous resizing.

Thanks for the report! I’ll take a look.

2 Likes
#80

When will this feature move out of beta? I’m looking forward to using this feature in my game.

3 Likes
#81

Hi @Ethanthegrand14 - A couple of critical issues came up that we have to address before releasing. We should have an updated ETA of when the full release will occur relatively soon.

Thank you for your patience and participation in the beta!

3 Likes
#82

Hi, sorry for the late reply!

The latter would be correct in this scenario, I would want it to take up the maximum size available regardless of the content.

And everything else you mentioned would be correct too.

I understand this is quite an intrusive feature request, and I figured out a way to do what I originally wanted to do (without AutomaticSize) anyways, so I guess this is just an “optional extra” if you do wish to consider it, no worries if not.

Thanks for your work!