I have a blueprint function (containing a few C++ helpers) that loads and parses a bunch of external resources and creates UMG widgets representing them and it takes a little over 5 seconds to run (that’s ~1 second for each of 5 folders) so I put together a loading screen and made the function switch the UI to that, update the progress bar with each step, then switch back to the regular UI afterward.
But of course, UMG does not update the whole time the BP function is running so in effect it just hangs for 5 seconds and never even shows my loading screen.
I understand that this is because my function blocks the main thread but I do not know how to do these operations separate from the main thread. It looks as though the multithreading system is not exposed to blueprint so I would have to move all of the functionality to C++ – and I suspect that changing the UMG UI isn’t thread safe so a good chunk of the work would have to block the main thread anyway.
Is there a simpler option I’m missing? Like a function I can call to force UMG to render on command?
The simplest option would be to inject some delay nodes in strategic places, allowing the main thread to run other tasks such as updating the UI. Now, you can’t have latent actions in a blueprint function, but maybe the function can be stripped down a bit so that it only runs through one of those five folders on each call (for example). That would let you call it from the main event graph, which does allow delay nodes. So… make a call, run a 0.1 - 0.2 second delay, then call again. This gives UMG and other things a chance to update in-between calls.
Thanks. In addition to moving the contents of the function to the event graph, I also had to replace the foreach loop macro with nodes that manually increment the counter and test the loop condition etc because Delay doesn’t work as expected in loops.
My blueprint is more disorganized now but it works 