Download

UMG lag problems

The user-friendliness of any UI relies on good response times to user input. I’m currently experiencing crazy lag with even the most basic setups in UMG.

To test this out in a very simple abstract form, I’ve created two things in UMG: a button and an image (currently just a white box):

bf8549c03a893b6d5070656aca2bc1669f5c9a63.png

I want this box to be invisible, and appear only when the mouse is hovering on the button, disappearing when the mouse is no longer hovering over the button. Here is the basic BP setup:

95cd3e95fedff9b7f9f03762e218fe257679338e.png

Here is the Level Blueprint, simply adding the widget and enabling all necessary mouse actions:

91115ba28a8010aac4883e6eaf889954248c285c.png

In both PIE and packaged builds there is a lag of around half a second between mousing over the button and the box appearing/disappearing. Half a second may not sound like much, but it’s very noticeable. It makes the UI feel clunky.

It seems to me that I’m asking for something very basic here – on a website, it’s very simple to code a button that responds instantly to mouse over events – and yet it’s laggy as hell.

Anyone else have this problem?

I don’t have the fastest computer in the world, but it is a Macbook Pro (late 2011) with 16GB ram and a 2.5Ghz i7, so I don’t see how something so simple could be lagging because of my machine.

Create a variable “thenameofyourwidget” of type “thenameofyourwidget”, obviously a reference.

Between Create UMG Widget and Add to Viewport set the variable “thenameofyourwidget”.

Hook return value into target of setvariable and the exec into the input.

I don’t know how it would change anything, but it works for me.

I don’t see anything wrong in your setup right off the bat, I will have to run some tests later if I find some time.

If it’s literally half a second then it could either be a bug with the button or you are running on low frame rates because half a second would mean 30 frames behind (assuming you are targeting 60 fps) which is obviously huge.

If you didn’t mean it literally then it sounds like you are experiencing software cursor lag which is a plague in many games imo.
Basically the default cursor you are actually seeing on your screen is not what the game sees but it’s instead a couple of frames or so behind.

I remember making a answerhub post about this a few years ago
https://answers.unrealengine.com/questions/146529/mouse-cursor-lag-very-noticable.html

I don’t know if this is what you are actually experiencing, it could be something else entirely but keep it in mind regardless.

Eh? that doesn’t have anything to do with this :stuck_out_tongue: you don’t have to save a reference of a spawned widget if you are just trying to put it on screen… just saying.

Aquazi: in the original project where I’m having this problem, I do actually do what you’re suggesting, because I need a reference to the widget for other things. Unfortunately makes no difference, still crazy lag.

TK-Master: this is very interesting. Did you overcome the problem by drawing your own cursor then? What’s the best way to do that? It seems to me though, that then the cursor will feel laggy, even if (in the example above) the box would appear when the cursor lands on it straight away. It’s essentially moving the lag to the responsiveness of the mouse cursor movement and away from the cursor’s interaction with the button, no? Doesn’t seem like it addresses the fundamental issue of UMG lag / unresponsiveness.

So I’ve recreated TK-Master’s setup from his post on Answerhub, and it does seem to be an issue with software cursor lag.

In this gif, you can see it is the red dot (UE4’s calculated mouse position – which is what it seems to use) and not the cursor itself which is triggering the mouse hover action on the button:

Mouse_Lag.gif

Here are some stills from the gif above, in case it’s hard to see what’s happening.

(1) Showing the mouse cursor itself on the button, no box appearing:

Screen Shot 2016-04-14 at 10.43.58.png

(2) Showing the mouse having passed, but the red dot (hidden behind the button for some reason…?) triggering the box to appear:

6fc26157fc88e32e64a36fe3b1c6ed820f7d439d.png

This strikes me as a really fundamental flaw in UE4 if there is no way around it. Drawing my own cursor using the same position information as that red dot is getting (Get Player Controller -> Get Mouse Position -> [X,Y]) does mean that when the cursor drawn that way hits the button, the box appears as expected, but it feels horrible – the way the mouse moves feels sluggish.

What can be done about this?!

Whoa that definitely looks a lot laggier than my gif, what’s your fps?

Unfortunately I don’t think there is much that can be done other than try to hide it with a custom cursor (at least that way the cursor is in sync :p).

I do agree that it’s a pretty big flaw and I’m fairly sure there are some older engines out there that have solved this problem but I’m not sure if it can be done in UE4… it would be great if an engine developer could give us a more technical explanation about this.

If I had to guess I would say that it’s probably microsoft’s fault here with directx api… but who knows.