Download

Creating a large ammount of Widget Blueprints - a bad custom or an okay approach?

I have a main menu widget blueprints, and to make the menus flashier, I have a large ammount of flying small 2D objects at bottom z order.

The way I have made them is so, that the main blueprint creates 2-3 new widget blueprints every second. In those created widgets, I only have 1 small texture, animation track, and some random float variables to change the placing, colour, z order, animation speed and opacity of the objects. When the animation is finished, this widget gets removed from the parent.

So in practice this means, that I have 20ish child widgets created and removed constantly. While I do not notice any performance drop (120 fps@1440), the specs of my computer are quite high. Could this approach cause problems to lower specs, or is it safe to do method like this?

Does not sound that bad since this is a main menu widget, there’s only 1 at a time and does not tick when hidden.

This *can *be improved by object pooling, though. Rather than destroying and creating widgets all the time, hide and show the ones that already exist. Recycle them :rolleyes:. It’s negligible performance gain (in this very instance) vs extra time spent on developing a behind-the-scenes algorithm no one will notice, sadly. On the other hand, it’s useful exercise that makes one sleep better at night.

It’s extremely unlikely that you’ll notice performance difference with 2-3 simple widgets created a second. But if you have 2 million bullets flying everywhere, object pooling comes in handy.

Yeah, thats what I felt. If a single bullet from a machinegun can be its own blueprint, my 2-3/s simple widgets with no physics etc. should be fine too. Asked just in case though, if widgets happen to have limitations/traps in them, z orders being more demanding than I thought or something like that I dont realize at this point. Thanks for the reply!

I Z-sorted about 120 or so widgets (roughly 20 elements each, with opacity based on distance from the camera) in a separate canvas (3d space map with stars and whatnot) and did not notice it affect performance, to be honest. And that’s on an old 7970.

Creating 120 in a single frame is another story all together, though.

To me, this sounds like a perfect time for pooling. Object Pool · Optimization Patterns · Game Programming Patterns

Creating and Destroying items in quick succession like this isn’t necessarily bad if you can retain the desired performance, but it definitely isn’t good for the performance-conscious. UMG Widgets are UObjects (assuming you’re using 2D widgets and not the Widget Component - if you are using the Widget Component then I’d strongly suggest changing this) and UObjects are fairly lightweight, but if you were using Actors for example (i.e. bullets in your second example), you ideally don’t want to be doing this.

Something to bear in mind is that you’re creating a lot of additional work for the Garbage Collector. That can have a huge impact on the project and eventually create stalling and whatnot. From a design standpoint, it’s also not very scaleable. What happens when you decide you want to have 40/60 of them being displayed? Suddenly spawning and destroying them constantly becomes impossible. I would recommend enabling the FPS and Object counters in the Editor so you can see how many objects are being created, if that number goes up very quickly, something is wrong.

In general, it’s always better to allocate what you need once, then reuse it if you can. IMO, it also feels cleaner :slight_smile: