The advice to “create the widget only when you need it” might be well meaning, but it’s not going to, by itself, create a meaningful difference in performance.
In older, more resource-constrained days, it was actually common to pre-create everything you would need, so that you knew that there was room for everything, and you wouldn’t suddenly run out of memory when you tried to show a dialog or spawn a bullet or whatever, and pre-created assets will cause fewer runtime pauses for asset loading, so there’s something to be said for that.
Adding the widget to the viewport, will have some cost, because UI events and rendering needs to dispatch to it, although a well implemented widget will not cause any particular performance slowdown when it’s hidden. Similarly, if the widget has tickers, and those tickers are super heavy, then that could also be something to look into.
The memory used by the widget is meaningless compared to the RAM of a normal computer, and any “cache” it uses would be flushed by a single frame of gameplay anyway.
So, why does the game slow down when your widget exists? It’s probably a bug in the widget, not a bug with how you show the widget.
Does the widget have properties that update on change? Do they form a loop of some sort? Are there deep loops or asset re-loads inside the widget implementation? If you turn on the pofiler, and check where the time is spent when the widget is created, what does the profiler say?
Also, what if you make a new empty widget, and create/show that, instead of your “pause menu” widget – does the game still slow down?
Those are the kinds of debugging steps you should take to hone in on what the problem is. All the talk of “widgets take memory and are wasteful” is totally beside the point for this problem. (Unless there’s a 128 GB 3D texture inside the widget or something, of course …)
