Optimizing UI performance by using multiple ScreenGui's?

Help and Feedback Scripting Support
#1

I’m currently at a point where I have a single ScreenGui containing the entire game UI.

A couple years ago, an engineer at Roblox mentioned during a conference that separating related UI elements into multiple ScreenGui’s was a good way to optimize how UI is rendered. It was explained that updating a UI element would cause the rest of the content in the same ScreenGui to update, which might get intensive if it contains a considerable amount of GUI objects.

Is this how the UI engine works in the back-end as of today?

Should I get started on separating my game UI into multiple ScreenGui’s to enhance the game performance?

#2

I don’t know, to put it simply, but I believe that it would be the same. A change in the engine at this magnitude would not happen without some announcement. Plus, I believe UI should be the last thing you should be concerned about, in terms of performance. Most of the time, you’re not going to have thousands of animations, correct? So, there is not much to worry about. Just remember that anything in large numbers can get laggy, so it’s really how many objects you have (such as images). Roblox optimizes the best they can on their end. What you should focus more on is, for example, the number of meshes in your game.

In addition to performance, organization would be better via multiple Screen GUIs. You can have Shop GUI, an inventory GUI, a perks GUI, etc. It keeps everything sorted like how folders do it. With one Screen GUI, it can get messy pretty fast.

1 Like
#3

I’m not sure what to conclude from this. I’ve been careful with other areas of the game when it comes to optimization, and UI is something I feel I’ve been slacking on lately.

While it is true that UI can often be negligible in terms of performance, the issue I first mentioned could very well be a valid concern. It was specified by someone who has a certain degree of knowledge about its back-end after all.

I could rework how my game UI is structured to use multiple ScreenGui’s to test the theory, but I was hoping I could get some sort of confirmation before getting started on such a big task. Adopting this strategy only for better organization isn’t exactly a good selling point as I’m satisfied with how it’s currently organized.

Should I investigate further, or just leave it as-is and potentially miss out on substantially improving performance?

#4

What you heard was correct. I’d even say that it’s fairly recently applicable too, considering that the most recent Gui engine optimisation I know of was made early last year.

I absolutely recommend that you separate your Guis. I once tried shoving my UI into only one ScreenGui but found that it’s simply not a good idea both for performance and organisation. Doesn’t flow or work as smoothly as I’d like it to. Being clear in what my Guis do has been working wonders (e.g. it seems silly to put loading screen elements in a menu’s Gui).

Ideally you will want to separate your ScreenGuis by the purpose of them. Static Guis (ones that aren’t updating) are significantly more performant. When a Gui element updates, this requires the Gui to need to be rendered. Using multiple ScreenGuis would isolate the performance cost into only rerendering certain changed Guis rather than all Guis.

Here’s a thread you can read up on:

I’d be willing to have as many ScreenGuis as actually necessary over using only a single. You’d miss out on the benefits that way.

3 Likes
#5

This is exactly what I hoped to see. Thank you so much.