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?
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.
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?
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.
Is this still the case even 3 years later? I am looking to optimize my UI’s and I came across this post so I was just wondering if this is still the case or did Roblox change how UI rendering works!
That is really up to you, there is no super noticeable difference between one and several. It’ll only mostly hinder your workflow if you put all of your UI into one ScreenGui and having tons of sub children, seperate them into different categories like Main Menu, Gameplay and Loading Screen.
Yes, this is still very much the case 3 years later, and you absolutely should still continue to separate your Guis if you want some gains on performance. Depending on how many moving parts and changes you make to your UIs (e.g. tweens!), you will be able to reap the benefits long term. Gui drawing optimisations only continue to get better with time and technology.
When you have a memory or drawcall-intensive experience, it does make a difference. This is not just the case with UI either - the world also needs to draw itself. This isn’t good advice and hasn’t been applicable since static Gui rendering improvements. It’s bad for organisation and performance. Taking care of your experience’s health early on can lead to benefits long term.