I’ve a question on UMG binding. It seems that it says UMG’s binding causes the widget to update only when there’s a variable change.
Hence I suppose it’s the most optimized way.
I do a very simple example of HP health bar and outputs a PrintString everytime the binding takes place.
But it seems that the screen is flooded with output messages even without any changes.
Does this means binding updates per tick? If that’s the case it would be less optimised to binding compares to per request update manually from BP.
The most accurate answer is, bindings are requested every time the slate attribute holding the delegate is accessed. In practice that works out to once or twice a frame.
Can this hurt performance: Yes. Don’t do tons of work inside a binding, they’re meant to mostly just access a value, maybe tweak it a little for presentation purposes and then return.
If you want, you can do the updates manually when stuff changes, however that tends to lead to lots of ‘the UI is out of date’ problems. So my recommendation is, use bindings for simple stuff, for complex stuff use bindings, to report a cached value that you update by some other means. Another reason people tend to make “View Model” objects that the UI is bound do that potentially invisibility do the caching and complex work that you may not want to do every frame.
I’ve just one question left…if it’s true the value is accessed so many times, I guess it’s always better to do manual update then?
e.g , why would I update my HP every tick when I can do it only when my hp change ( linkto OnDamage or something ) and why would it
“tends to lead to lots of ‘the UI is out of date’ problems.”. Would you care to elaborate.
If it were always better, I wouldn’t have gone to the trouble of introducing bindings
Lets take health as an example, you expose a public Health property on your Character. I shoot him, and call Damage, which internally adjusts the health and then fires an event which you hook and then update the UI. Cool. Later - you introduce health pickups, and instead of damage, it heals you. Now you have to have have an OnHeal, or maybe you generalize it as OnHealthChanged. That’s not so bad for one property, but keep in mind, you must always remember in your game code to never directly modify Health without calling OnHealthChanged, or your UI will be out of date.
Imagine doing that on every value you ever want to display in the UI that could conceivably change due to gameplay. Player Name, Weapon stats in an RPG (maybe you want to show the value with buffs included), the list can get pretty long.
With Binding you avoid all those problems, whatever the value, that’s what the UI shows. In the future we can improve the performance of bindings, (possibly with invalidation options, time based invalidation, or maybe with events). Which is why it’s better than doing it in Tick, and if all you are planning to bind is a handful of properties, it’s not worth worrying about the performance, so better to err on the side of bindings instead of manual updating.
In the end, we provide both so that you can pick which ever you’re more comfortable with, or will fit your use-case better.
Could there be an option for more control over the tick and binding update frequency? It seems like in most cases it is all or nothing, when really we just want the frequency to be some fraction of what it is hard coded to be.
i know its 2017 (only 3 years after this question), but you can always make a timer event in your UMG Widget that updates variables such as health, stamina, etc. on the time frequency that you set it to (as opposed to just having it bound by event tick)…
Of course not. They updates only when widgets are visible. You can ensure that by adding PrintString inside bind Function. It prints only when widget is visible.
