Creating a UI widget makes my game unplayably laggy

Development Programming & Scripting
,
1

Hi All,

I am attempting to add a “pause menu” in my game and as soon as i “create the widget” from within the player controller using this logic the game basically stops functioning:

image
image427×254 21.2 KB
(this is called from the EventBeginPlay)

image
image2098×301 94.4 KB

The menu itself has a couple of buttons (most are not handled) and the EventGraph for it looks like this:

image
image2639×784 317 KB

I am overloading the use of the “esc” key to trigger the menu but the “pause / unpause” logic looks like this in my PlayerController EventGraph:

image
image2041×401 99.5 KB

Even when the pause menu has not been activated (using esc) the lag in the game is EXTREME - to the point I initially thought inputs were completely broken - but it turns out they do still work - just with a lag of about 5 seconds.

Before you ask, yes I did follow a video for this: https://www.youtube.com/watch?v=qPpouAIFkec

Does anyone know what’s going on? I am not even sure how to debug this…

2

(post deleted by author)

1 Like
3

  1. because if i break the link in the begin play event (and don’t create the widget) the game performance goes back to normal

  2. surely creating it once and then toggling visibility on the pre-existing widget is more efficient than creating it every time it is needed?

  3. is it not better to just have one? what’s the mistake that’s so prevalent?

4

(post deleted by author)

1 Like
5

Right so did the above - it now creates the pause menu widget when you press esc - so before the widget is created it works fine - as soon as i hit esc (and the resume the game) - both of which work - the game then becomes extremely laggy

So it is definitely something to do with the creation of the widget

6

Here’s how it’s triggered:

image
image1954×770 145 KB

7

Also this is not a memory issue:

image
image817×486 29 KB

task manager when the “ultra lagginess” is happening

this is task manager when no pause menu (i broke the link that creates the pause menu) - it’s actually using more ram with it not being created - less CPU granted - but not sure 9.4% is really pushing my system very hard:

image
image897×427 26.8 KB

8

(post deleted by author)

9

(post deleted by author)

10

it could be because you have it on triggered which is usually basically tick, put a print string there to test.

usually for this stuff you’d use started instead of triggered.

In my opinion the visibility vs created/destroy method just depends on how often the widget might be used. Even if you RemoveFromParent garbage collection isnt instant or free so visibility is often the better idea. In this particular case either is fine.

11

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 …)

12

(post deleted by author)

13

Explain to me how the profiler told you that the memory usage was the cause of this UI widget causing slowdowns?

My expectation is that some other mechanism, such as un-canceled tickers, repeated layout re-computation, or something like that would be the culprit.

14

(post deleted by author)

15

expect possibly and probably the ‘Triggered’ Pin

1 Like
16

This is just voodoo cargo culting. If you’re interested in actual engineering, you need to actually debug this problem in the profiler and find out what it is.

Memory comes from somewhere, and you can be specific about it. And even so, memory by itself does not cause performance drops, unless there’s some other resource that gets impacted by that memory, by visiting all of it every frame for example, or by force-loading something like a too big texture into a too-small GPU RAM area. These are fully understandable, deterministic causes of performance loss, and you can’t build a correct, robust game without understanding what the problem actually is.

Many times, the thing you think is causing the problem, is actually just triggering some other, underlying problem, and even though you think you “fixed” it by “not triggering” it, some time later (typically at the least convenient time possible,) the problem will be re-triggered again, by something totally different.

If your goal is not to understand the system, and if your goal is not to practice sound engineering, by all means, wave that dead chicken, observe that it currently doesn’t hurt, and rush on to something else. After all, you made it not hurt right now!