UMG functions hit on on fps

I was trying to set a text in an UMG text widget by using a custom event and ‘set text’, this caused new text to be displayed on old text when I changed the actual text. It was essentially never clearing the text when the text got updated. I even tried setting the text to nothing before updating, removing the widget from the viewport before displaying new text etc…

What worked was updating the text in its own bound function but I have to do some logic inside of the bind function.

I’m wondering if this text keeps updating on every tick now instead (a custom event wouldn’t (?)), or if UMG is smart enough to update it whenever variables get updated (I cast to a playerController, get a var and do some logic on it)?

The main question is if one way has a bigger hit on fps over the other?

Thanks.

I’m not sure on the inner workings of UMG but, from my own experience, using binded functions seems to have a much bigger impact in fps than changing the contents on events.

I tested about 200 umg widgets updating simultaneously with binded functions (1 to set text and 1 to set a texture) and my fps was around 20. Settings those changes to be made only on certain events got the fps back to 80-90.

So they do seem to update every tick (Although a confirmation from Epic on this would be amazing)

Thanks for the feedback!

On that note, if anyone knows how to then update text without it displaying over the old text that’d be great. Again - using ‘set text’ in an event just sets the text without clearing what was in that text widget before, resulting in a big mess of letters. :frowning:

That’s quite odd, I’m just selecting the widget in which I need the text changing with “Set text” and the text is replaced correctly.

Just like this:

set text.png

Hmmm… thanks. I wonder if it’s some error in user case then. I will take a look over the weekend. The only thing I can think of is I might be adding the widget multiple times (overriding my widget ref var) and when I change the text I’m doing so on a new widget with a previous one lying underneath… That could be it actually, I should’ve done an isExist type check first. :confused: