Some fonts now take anywhere from 10 to 15s to load upon entering a game in both studio and live servers. During their loading time, fonts appear to default to an entirely different font while waiting for the correct one to load. This causes any TextBounds reference to return the bounds of the placeholder font rather than the font the game intended to use.
Can you provide more information about the setup that you’re running into this? I can’t reproduce this - all the builtin fonts load instantly, and cloud fonts load after a short (<1s) delay.
I have a handful of assets which load into the game which may play into the long loading time. I have a pretty standard setup and am able to replicate the issue by cloning the UI from my game, although it loads much quicker than my actual game. I’ve sent you a studio file containing the UI if this helps replication:
Edit:
On second glance, the file I sent uses Arimo, which I believe is a cloud font, and the source sans font (which is the cash display at the top) doesn’t seem to run into the issue unlike my initial report. Typically when this issue occurs in my game, other assets in my game such as images and meshes struggle to load for a brief period in both studio and live servers.
If it were just Arimo I would understand, but Arial and Source Sans Pro, unless switched to a cloud font without notice, shouldn’t have this issue. I can confirm a few things:
This issue does still happen in my game with Arial.
This issue does not occur in every instance the game runs and seems to happen more if Roblox’s servers are slow or the device struggles to load assets.
Not all fonts are impacted by this issue.
Although the issue with assets loading slowly has been around for months (see video below), the font issue definitely began around the time the Builder font was announced.
Game struggling to load assets then Arial & Source Sans struggle to load:
This issue is also prevalent within some of my games, but I thought the crazy loading times were just a caveat that came with using fonts stored on the cloud so I never reported it.
We load in lots of images on join which take quite a few seconds to fully appear, so I believe this is something to do with what’s being prioritised in the loading process. We use :PreloadAsync() to do this.
We try our best to use mostly built-in fonts like Gotham (which is now being deprecated) to avoid this behaviour, and it’s been a pain up until now. Let me know if you need a place file.
necrobumping bc i was encountering the TextBounds part of this thread
tldr: preloadasync the screengui
i have an interface util function that appends an imagelabel to a textlabel and listens to TextLabel:GetPropertyChangedSignal("TextBounds") to adaptively offset the imagelabel for subsequent .TextBounds changes and it looks something like this ↓ when it works properly
i really dont care to find out the underlying problem but from what i observed is that when the .FontFace of a TextLabel loads, regardless if it’s a built-in or not, the TextBounds property changes but any connections made to the property change itself don’t fire
obviously, Vector2(10, 16) is not Vector2(14, 26)
either that or its a race condition, regardless it’s really out of the devs hands and i dont anticipate a small problem like this being put to rest
how i fixed my case:
task.wait() does work, but i’d rather stare directly into the sun than spam unnecessary task.wait() calls
it’s impossible to PreloadAsync a Font object, and PreloadAsync on a font assetid (even if its a built-in font) technically preloads the font but it doesn’t fix the textbounds problem
it is possible, however, to PreloadAsync an instance
and in this case i PreloadAsync the ScreenGui instance that contains all of my game ui elements:
… again this could be a race condition and the extra 0.1s it takes to preload a screengui might be long enough for the textlabels to load, but im just throwing this out there bc i havent found any other way to fix it
I feel this is more an issue with TextBounds being a very difficult property to work with, a realistic fix would be an API method that supports the new cloud font APIs?
Thanks for all the info! We’ll continue to monitor the issue for a while longer. If there are no further occurrences or additional reports from folks, we will consider closing this ticket. Please don’t hesitate to inform us if the problem persists or if you have any other concerns.
Just FYI I’m about to close this ticket as the issue is not occurring as much. Please let us know if you are still experiencing this problem or open a new post. Thank you!
