How you can see my mouse goes little bit faster than widget.

My movement algorithm is:

Vector2f delta = new Vector2f(cursorPosition).sub(cursorPositionPrev);

I am using LWJGL and my own GUI solution.

Here is visual structure of event processor part. One thread for processing events generated by user and another thread render current gui state.

Even if rendering and processing events is in one thread the issue is still exist.


So what can I do to make to avoid this delay and make widget to keep up with the mouse movement?


  • \$\begingroup\$ Where do you update cursorPositionPrev? Inside the listener? In the same place you update cursorPosition? \$\endgroup\$
    – Bálint
    Commented Jul 19, 2016 at 5:29
  • \$\begingroup\$ Yes, in the same place. \$\endgroup\$
    – SpinyOwl
    Commented Jul 19, 2016 at 7:49
  • \$\begingroup\$ As I think the reason is that there are some calculations between updating current cursor position and updating widget position. I created event queue so while processed one event on mouse move generated more events that will be processed later. \$\endgroup\$
    – SpinyOwl
    Commented Jul 19, 2016 at 8:13
  • \$\begingroup\$ I've checked and found that sometimes event queue contains one more not processed mouse movement event when another processed, so it can be the reason but sometimes lag is large enough (about 5-7px). \$\endgroup\$
    – SpinyOwl
    Commented Jul 19, 2016 at 20:53

2 Answers 2


So, you say, that when you update the cursorPosition variable you update the cursorPositionPrev variable too. This is not a good idea and this could be one of the reasons why it goes a bit slower than your mouse.

Your update method gets called 60 times per second, but the mouse listeners can run way more times in a second.

So, let's imagine this: your mouse moves 3 pixels, you set the mouse position a the previous positions correctly.

The update method still doesn't run but the mouse moves another 3 pixels and the listener gets called again, you set the mouse position correctly, but the previous position will be wrong.

The update method runs and sees, that the distance between the previous position and the current position is only 3 pixels, while the user moved his mouse 6 pixels.

To solve this you need to move the line of code where you update your previous position to the end of the update method.

  • \$\begingroup\$ I've just updated topic. In my opinion moving this line of code to the end shall not entail any changes. Another way (some hacky solution) is to hide system cursor and draw my own - in this case there are no visible lag :) \$\endgroup\$
    – SpinyOwl
    Commented Jul 19, 2016 at 20:47

I found that the reason is my event queue realization and the second reason is that I use OS cursor (OS cursor is hardware accelerated).

Mouse position is current mouse position obtained from GLFW, lag - difference between current position from GLFW and from event system. Here is approve:

LAG example 1 LAG example 2 LAG example 3


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .