Hitches occurring when UMG is initialized, has been less prominent after UE4.13. So let me ask some more questions.
If we want to achieve further speed-up, there is no way but to parallelize parts where serial processing is executed. So, is there any parts that would cause a problem due to their data structures if they should be parallelized?
For example, here is a call stack for the creation.
The parts that can possibly be parallelized are **Property::InstanceSubobjects() that are called from UUserWidget::NewWidgetObject() and UWidgetTree::ForWidgetAndChildren() that is called from UUserWidget::Initialize().
In terms of the data structure of Widget, is it safe to create child’s in random order as long as the parent has been created already?
Also, is this the case with the initialization, as well? (i.e. Is it safe to initialize child’s in random order as long as the parent has been already initialized?)
I personally would caution any use of parallel initialization of UObject trees. It may be possible if you were very careful to go wide, and not run any other game code at that moment when creating each top level widget.
What I can suggest is - you should precreate heavy widgets at map load, and just keep it alive until needed. When it goes away - don’t just destroy it, keep the UObject alive and just show it again to avoid the hitching behavior.
If there’s a long list of widgets, you should pool them and just rebind the same widget to different data rather than a constant churn.
It’s safe to construct children in any order - however they need to be added to the parent in the order specified at design time or they won’t be sorted as expected when drawn - also you definitely wouldn’t want the add to happen on multiple threads that would not be safe.