Hello, maybe this is a simple question, but I didn’t find answer by quick search.
What is the best way (in terms of performance) to “hide” a widget? If I understand correctly, there are three possibilities:
Just set visibility of widget to
hidden/collapsed. When widget is
needed again - turn on visibility.
Remove widget from viewport or
from parent. When widget is needed
again - attach it to parent.
Completely destroy a widget. When
widget is needeed again - spawn it
and attach.
So let’s say that we have a widget that will quite often be opened/closed. Like player’s inventory, dialogue, journal, etc. I think that destroying widget will be a bad choice but what about the first two? Is there a big difference in performance between simply changing visibility and removing from parent? I know I could’ve make some tests but maybe someone already knows the answer?
If you have followed the basic UMG tutorials that have gone over let’s say a Pause Menu, then that’s pretty much going to be the same setup for every Widget that you need to open and close dynamically.
Okay, I’ve made a quick test with blueprints.
After pressing G test widget 3000 times is hidden and shown again. This gives small spikes, somewhere around extra 8-10ms lag.
After pressing H test widget 3000 times is removed from parent and then added again. Now spikes are huge. See for yourself:
Why are you even trying to open and close this 3000 times? I am assuming you did this on a loop. If so, of course you are going to see some lag spikes…
I don’t get what you are trying to do. Like I said, as long as you do the Menus correctly. You should be fine. Please show us your BP implementation so we can see what you are doing wrong.
Finally, and hopefully, you are not doing anything on tick, but C++ would be a bit faster, but truthfully, I think your implementation is wrong with is causing the hiccup.
Of course I’m not going to need to open and close widget 3000 times in one frame. That was merely to test what’s the difference in performance. The difference is that removing-adding is somewhere like 10 times slower than hiding-showing. That’s it.
Its not about remove vs hide which is faster it is about what consume less cycles, construct widget and keep it collapsed or consturct - deconstruct every time.
i’m not understanding the confusion because clearly his test is showing that it is 10 times faster to Show and Hide than it is to Unparent then re-Add To Viewport. I’ve seen this question asked a million times and it’s evident that noone knows the answer with any certainty. It would be extremely helpful if someone with an actual understanding of how the engine is handling this process could answer this and settle it once and for all since there are numerous posts about this all over the place. I think that many people would like to know which method is best to use from a performance standpoint since the general advice is to use the Unparent then re-Add approach but most wonder why this is the general advice when it’s clearly much faster to just show and hide. Is there a good reason why anyone would use one over the other? I think some clarity on this issue is needed in the documentation for creating widgets to avoid this question being asked over and over with no clear answer as to the best approach.
So I’m learning UE and creating UI at the moment. My question on this topic is, what is more efficient for draw calls? I guess that more performant for gameplay is destroying and creating widgets as shown in the Pause Menu tutorial, because hidden UI elements may be expensive (consuming draw calls) if are not shown, hence lowering overall fps/ms while playing the game. Am I correct?
Just to add extra info about the topic… Adding and removing calls Construct and Destruct functions in the widget (Destruct when removed and Construct when added). So that could be good or bad depending on what you want, for example handling bindings to delegates, initializing and resetting stuff. If you want that to happen use remove and add, if you dont just use hide and show, use the Collapsed visibility state to make sure the hidden object is completely ignored by the layout.
comments like these are hilarious because you don’t answer the question, act patronizing, and now years later your link is broken and that page doesn’t exist. super helpful
I have been using hide and show because I need bindings to be persistent. I think that’s the main concern.
