Input lag when creating and removing widget button (Also can break player's input and potential memory leaks)

[UselessMouth (Richard Chirkin)]

Summary

Widget creation takes a huge processing time.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

UI/Tools

Steps to Reproduce

Make a button like in this tutorial under «Button Interactions» — Making Widgets Interactable | Unreal Editor for Fortnite Documentation | Epic Developer Community

Expected Result

1. Button should appear instantly on the screen after widget creation.
2. Button should disappear instantly from the screen after widget removement.

Observed Result

1. Player triggers something in the game that invokes button creation procedure code which includes AddWidget().
2. Player’s input gets consumed by widget instantly, but there is no button on the screen.
3. Player waits around 1 second, unable to do anything.
4. Button appears on the screen allowing to interact with it.
5. You click on a button that invokes button removing procedure code which includes RemoveWidget().
6. Button stays on the screen around 1 second, player is unable to do anything.
7. Player finally regains control of the character.

Platform(s)

All

Additional Notes

See the first reply for additional links.

The workaround for all of this should probably be like this:

1. Initialize widgets on first spawn of the player.
2. Hide the widgets until needed.
3. Show widgets when needed, consuming player’s input for button interaction.
4. Hide widgets when player is done with button interactions, allowing player to regain control of the character.

Though you can not use this workaround right now, because the widget consumes player’s input on its creation, disallowing to change input when needed — only by removing widget player can regain control, but removing widget process is slow and, as I found out, the widget doesn’t actually get properly removed from the memory, introducing memory leak, which can slow down the server.

You can find potential memory leak code in the first reply.

About breaking player’s input:

1. Create widget, which consumes player’s input.
2. Hide the widget from the screen (do not actually remove it from the code).
3. Player is unable to do anything in-game — player can only invoke Game Menu and that is all.

[UselessMouth (Richard Chirkin)]

My original thread with the issue:

[BUG] Huge input lag when using UI widget buttons — Also you can break player inputs entirely

So if you create buttons through Verse code, like in this tutorial, when you do something for button to appear, you wait almost 1 second (!) to be able to see and click the button. Same goes for button closing. When you click on a button for it to disappear you wait almost 1 second (!!!) before it disappears and player regains control of the character. I am 100% sure this huge lag happens because of these two functions: player_ui.AddWidget() # and player_ui.RemoveWidget() So I tried to use w…

Additional old threads:

Trying to change the InputMode := ui_input_mode.None

Hi I am tying to create an interactable Canvas that can appear and disappear with 0 delay I am saving already the Canvas in a map and I use it every time I need it. The delay is pretty low, but I need it to be 0 Canvas:=MakeCanvas() set AllAgentsCanvasUI[Agent] = option{Canvas} The only way that I found to get a perfect delay is using the functions Canvas.SetVisibility(widget_visibility.Collapsed) / Canvas.SetVisibility(widget_visibility.Visible) the problem is, you can not change player_ui…

Does anyone else find Verse UI really slow?

I have been messing around with different UI to create a shop in FN. I originally created a widget and dialog device but that has a few issues. Firstly, you can’t really change anything about the UI at runtime. Secondly, we are stuck with an extremely low 6 buttons (5 if you want to take one out for a exit button). These issues led me to the terrible verse UI code. The benefit here was that I could create more than 6 buttons and bind them all. What I did not expect was just how slow the UI is. …

Potential memory leak code to reproduce:

https://gist.github.com/MattRix/912fd98e498a3e653457986bd65e8f94