UIScale does not apply properly with AutomaticSize

Reproduction StepsReproduction:
Add a UIscale to any textlabel with automatic size enabled, scale up the UIscale.

image
image
image

image
how it looks

image
how it should look

Expected Behavior
The x/y sizing of the label should stay consistent.

Actual Behavior
The scaling is applied twice to the label, making it bigger than it should be

Issue Area: Engine
Issue Type: Display
Impact: Moderate
Frequency: Constantly

16 Likes

Too add to this, with current behavior, UIScale scales the TextSize behind the scenes (according to the UIScale’s Scale property). This makes the AutomaticSize property account for the space of the newly scaled TextSize and then the UIScale is applied to the new AutomaticSize. Seems really weird.

It would make a ton more sense if it respected AutomaticSize over the UIScale like your example instead of applying the UIScale after AutomaticSize calculations.

1 Like

This happens with ScrollingFrame’s CanvasSize properties too, which is made triply frustrating by the fact that AbsoluteContentSize also gives an incorrect result, making true automatic sizing significantly more hacky.

5 Likes

Just following up to let you know this issue is acknowledged, filed into our internal database and not forgotten.

Thanks for your patience!

4 Likes

I’ve designed full UI sets for several different projects expecting this basic functionality to work. I’ve just been following basic conventional UI rules with offset-centric design, and it doesn’t work because of a bug… pleaseee

2 Likes

For anyone reading this in the future, I made my own AutomaticSize that works with UIScale:

local TextBounds = Text.TextBounds
local UIScaleMultiplier = 1 -- Whatever your UIScale is set to

local CalculatedOffset = Vector2.new(math.ceil(TextBounds.X / UIScaleMultiplier), math.ceil(TextBounds.Y / UIScaleMultiplier)) -- Un-multiplies, fixing the improperly 2x auto-sized TextLabels.
local CalculatedSize = UDim2.fromOffset(CalculatedOffset.X, CalculatedOffset.Y)

To implement this at scale, you’ll need a component-based UI framework like Fusion, and global state management to store a universal scale multiplier.

My full Fusion implementation
local TextBounds = Value(Vector2.new())
local TextWrapped = Value(true)

return New "TextLabel" {
  AutomaticSize = Props.AutomaticSize or Enum.AutomaticSize.None,
  Size = Computed(function()
    if Props.Size then
      return Props.Size
    elseif Props.AutomaticSize or not TextBounds:get() then
      return UDim2.new()
    end
    local TrueTextBounds = Vector2.new(math.ceil(TextBounds:get().X / States.GlobalUIScale:get()), math.ceil(TextBounds:get().Y / States.GlobalUIScale:get()))
    if not TextWrapped:get() then
      return UDim2.fromOffset(TrueTextBounds.X, TrueTextBounds.Y)
    else
      return UDim2.new(UDim.new(1, 0), UDim.new(0, TrueTextBounds.Y))
    end
    return UDim2.new()
  end),

  [Out "TextBounds"] = TextBounds,
  [Out "TextWrapped"] = TextWrapped,
}
1 Like

Hi @x_o , we have increased the priority of this issue in our backlog and we will investigate it soon. Thank you for your patience!

1 Like

When will this issue be fixed? It hits my development experience very hard.

I’d like to add that I’m having issues with text size when AutomaticSize is enabled, the frame doesn’t size the text bounds correctly when UIScale is active.

Hi @pozzzy333 , we are working on a fix for this issue and hopefully it can be deployed soon. Thanks for your patience!

2 Likes

I just want to mention I’ve also run into the same problem. I suppose the problem is same for all Automatic values, as the actual Automatic value is multiplied with the UIScale.Scale.

What’s worse, even manual set up of CanvasSize is broken. You can see the not-wroking CanvasSize when you just use Menu.CanvasSize = UDim2.new(0, 0, 0, 50) and if the Menu is inside an object with UIScale, Menu.AbsoluteCanvasSize is equal to UDim2.new(0, 0, 0, 50 * UIScale.Scale). I haven’t tested it for TextLabels yet but I remember I was wondering during playing my game why the text of TextLabels (that represented a time value) were over the following TextLabel when in their properties is an AutomaticSize value turned on, meaning the actual Size should be calculated by the size of the text itself. (Due to UIScale.Scale being less than 1, the actual Size of the TextLabel was smaller than the size of the text, meaning the text got out of it’s box and so was over other objects around.)

I’m glad I found out it is not my mistake, that not only me faced this problem and that Roblox is trying to fix that (potentionally, hopefully).

1 Like

Can we have any updates on the “soon” situation?

Hi @ItsNimbusCloud , we have rolled out an update previously to fix the issue in the original post. Are you still running into any related issue? If so, could you share a repro file with us for a further investigation? Thank you

This bug is still happening for me. Let me know if I should file another bug report!

Here’s the repro file:
ReproUI.rbxl (63.3 KB)

As you can see, the only difference between the left and right UI is the UIScale value. Yet the spacing below the “Many things are subject to change and some things may break” TextLabel has a much larger proportion for the left UI.

I also don’t know if this is related, but some players are reporting that the UI text is cut off. But I cannot replicate this in studio even though it’s the exact same UI and it’s happening on PC.

1 Like

Can confirm this is happening still. Very frustrating

4 Likes

It’s still happening. Any news on whether this is being worked on or if we should file another report?

Hi! Still running into this issue, any new updates? @CharlieGordonnn

Hi, I believe the issue in the original post was already fixed. If you are running into related issues, please open a new bug report, and provide the repro files with the current and expected behavior info in the post. Thank you!

1 Like