I have read conflicting information about using bindings for UI widgets. Some people say the engine updates every binding every tick (thus maybe causing a performance issue). Other people say bindings only update when the underlying value changed (how is that cheaper to monitor I dont know?)
In my case for example I want to bind 16 image widgets to represent 16 “buffs or afflictions” on the player.
The buffs and afflictions are stored in an array so I bound the visibility property of each image to a short blueprint that checks if that index of the array is valid (exists). I also bind each image to the “icon” element of the matching index of the array (if exists).
So great it works fine, but has me wondering if there’s a lot of wasted processing going on under the hood with this arrangement?
Am I better off to use an event driven system to show and hide the icons?
Put a Print String there and see for yourself. Why trust internet people.
Am I better off to use an event driven system to show and hide the icons?
Yes, as per official documentation (and common sense!, and it’s easier to debug):
One thing to note:
Widgets that are off screen (hidden, out of screen space, etc) do not tick. So if you’re brining up the inventory widget and the game is paused in the background, it does not really matter if you’re polling variables 60 times per second.
So great it works fine, but has me wondering if there’s a lot of wasted processing going on under the hood with this arrangement?
As much as I try to do everything Event Driven way, I seriously doubt you’ll be able to measure a performance impact of a couple dozens widgets casting, taking structs apart, formatting data and setting fields.
If you’re targeting a 360MHz displays, that’s another issue and I’d avoid UMG / Blueprint altogether.
Ok thanks, I hadn’t read through that part of the documentation before. I see now that bindings (both BP function or property based like your second post) always poll every frame. I even see “hidden” widgets polling via print string now that you mention it, so I don’t know about that off screen widgets don’t tick.
Looks like moving to event based would be most appropriate for my case.
I destroy my BP whenever they aren’t being used unless there’s a need for it. Whenever I need to do like an inventory for example I check to see if the inventory widget is valid, if it isn’t then I spawn it. Invalidate the blueprint after you’re done (after it’s done doing the closing inventory animation).
I’m not entirely sure if this is the most efficient way to go about it.
That seems like a decent idea for a “once in a while” widget like an inventory or a map.
In my case the buff/affliction/hot/dot status widgets are always on screen showing status for the lead unit currently selected so that doesn’t make sense for me.
Event bindings should work fine if performance does in fact become an issue. I won’t adjust until then.
To be perfectly honest, the inventory is very the last widget I’d attempt to destroy / recreate. It’s very likely to be the heaviest, most convoluted widget in the game, hooked up to a bazillion places and numerous other systems.
This is a show / hide candidate. Combine it with List / Grid View and the memory footprint is no longer an issue even if you have thousands of items.
The inventory UI should probably just be that, a UI and nothing more. Everything I do is performed outside of the UI but if there are changes and the UI exists, then it’ll update it there as well. Changes made go to a custom function within the UI widget if the widget exists. No external binding necessary
lol no. The player retains the data and passes over that data as needed when the UI is open. Meaning when you open the UI it repopulates the inventory using cached data from the user’s own database. If anything changes while the inventory is open, then it sends that data over on said change but once the inventory widget is destroyed, it doesn’t attempt to send it until it’s opened again. If you were to have say, two dozen menu dialogs like your inventory, a knowledgebase of known monsters, map data, etc… The performance will decrease with every menu you have even if you’re not using it but the way I do it, it only happens if you have everything opened at once.
Additionally, because I don’t bind anything from an external source but use custom trigger events that updates the data automatically, it doesn’t work on ticks and gets updated only as needed.
So you do rebuild the UI every time you open the inventory. Odd, sounds like a waste of resources. But it depends on the scope, I guess. If you kept it alive, hidden, you could update it behind the scenes to be ready whenever. Just pop a single update to whatever element needs it.
I don’t get it. So you rebind dispatchers every time the inventory opens, too?
Would you mind sharing why you opted for this very solution?
It’s better to do everything in a UObject class (in BP, a struct works just fine in C++) then build UI to reflect the data.
That’s of course just a best practice, doing it with hide/show is usually perfectly fine. It really depends on what’s ticking, how many items are ticking, how much memory images and other things may take up, etc. And of course your target platform. I prefer to recreate the UI every time it’s called for the sake of using resources for other things and portability reasons (might be fine on PC, but porting to Switch could leave you without precious RAM).
The only exception is a monster Tree View or something that can’t be created in a reasonable period. Even then though I’d prefer to break it up into smaller tree views on separate menus or nest tree views so all the items aren’t created at once and it forces me to rethink organization.
Stuff like last scroll level and last page open are easy to serialize to a UObject then reference when the UI is opened. It’s a lot of extra work but it’s what I learned and prefer. It’s like putting all of your toys back in the toy chest before you play with them again vs shoving them all under the bed
It’s not a waste of resources though, it’s basically what Jared said, MVC. Coming from web development it’s a technique that I apply to many things. There’s no point in always updating variables at every tick when they can just be updated when they are changed. Additionally, there’s no point of always having data loaded in the background if it’s not necessary. The inventory data is loaded instantaneously anyway, it’s not like it puts a big burden. Small games probably won’t ever notice a difference but I think that this is the better practice to follow because it’s a “use resources when you really need it” rather than an always-on thing.
For things that might require a lot of computation power or has a lot of data to load, make the game show a load icon as it is reading the file(s) / rendering or implement some type of animation to make the player feel like they’re not waiting. It’s better than having an overhead of 2gb of just menu data or something
At no point was I talking about updating anything on Tick, why even? Creating and laying out widgets is performance intensive. For a huge number of objects you’ll be using tree / list / grid view anyway so the memory footprint will be negligible.
The inventory data is loaded instantaneously anyway
The data is already loaded (unless we’re using soft references), sure. But creating 100 widgets every time I press ‘I’ only to have them scooped by the GC later does not sound like the best idea around. To each their own - was genuinely curious as to how the approach can be justified. Ideally, one’d choose the best tool for the job - target platform being the crucial bit. I’ll agree with that.
For things that might require a lot of computation power or has a lot of data to load, make the game show a load icon as it is reading the file
Or hide / show the widget instead to have it available immediately and without fail What would you prefer as the end user? Instance access to the inventory screen or watching a spinner, waiting for the widgets to rejiggle text or forcing a premature layout prepass.
I’ll keep doing it my way because it best suits how I do things. I don’t think we understand each other on what we’re talking about so we’ll leave it at that. I much prefer generating UI when needed then to always have it on. I made my point, you made yours. Now it’s up to OP to decide what is best for them.
What would you prefer as the end user? Instance access to the inventory screen or watching a spinner, waiting for the widgets to rejiggle text or forcing a premature layout prepass.