Over two frames of lag in mouse movement

[pgimeno]

Krita may use OpenGL, I don't know if it's always in use or it's optional, but I'm positive GIMP doesn't:

Code: Select all

$ ldd `which gimp`|grep GL

$ ldd `which krita`|grep GL
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f3bb5199000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f3bb4282000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f3bb424e000)

Edit: Indeed in Krita it's optional.

[cloudberry]

Krita may use OpenGL, I don't know if it's always in use or it's optional, but I'm positive GIMP doesn't:

GIMP is a GTK app and therefore likely uses something like Cairo, which itself ends up using OpenGL either through the display manager or directly. GIMP itself just doesn't directly call GL, similar to how love2d uses SDL as an intermediary layer.

Unfortunately, I do not know of an SDL2 app to easily test this with, that would probably the the most directly comparable.

[pgimeno]

I think that the first answer here is pretty much spot-on: https://stackoverflow.com/questions/191 ... rough-glfw

I've used a 4X speed (240 FPS) camera to track the exact frames in which events occur, and the delay is between 1 and 2 frames, and it's pretty often in between.

This sequence shows the first frames where the moved cursor/box becomes visible, omitting the rest:

FrameDelay.gif (407.69 KiB) Viewed 3898 times

Note how in some intermediate frames, the square is clearly halfway at some place between where the two cursors were. That tells us that the lag is somewhere between 1 and 2 frames.

So I've made an experiment: let's measure the mouse position near the end of the frame, instead of at the beginning.

Code: Select all

local present = love.graphics.present
function love.graphics.present() end

function love.draw()
  local x, y = love.mouse.getPosition()
  love.graphics.rectangle("fill", x-5, y-5, 10, 10)
  present() -- waits for vsync
  -- Sleep for most of the frame time before the next round of
  -- event polling
  love.timer.sleep(1/64)
end

And indeed, the response was quicker.

[grump]

There's also this:

SDL_GetMouseState() returns the mouse position as SDL understands it from the last pump of the event queue. This function, however, queries the OS for the current mouse position

Love uses SDL_GetMouseState() in love.mouse.getPosition, that's why I used the ffi call. I didn't check if it makes a difference. Might be worth a try.

[Xii]

Ah ha, so it's a rendering delay issue.

I tested further with love.window.setTitle and that displays the latest mouse position correctly.

The problem is that the graphics pipeline takes too many frames to draw the software cursor, not that the mouse position doesn't propagate fast enough - it does.

To work around this, I guess you'd have to extrapolate the future position based on past movement, but that seems... hacky.

[BrotSagtMist]

So I've made an experiment: let's measure the mouse position near the end of the frame, instead of at the beginning.

Didnt i already post that? Do ppl even open stuff?

So split by colour:
Blue- end of frame creation using love.mouse
green- grumps ffi thing at end of frame
red- _normal_ löve solution
We clearly see that blue lags a bit more than one frame and red a little bit less than two frames and the ffi grabbing is ahead of the normal love function by a very tiny amount. (ffi was called first so its not caused by code order)

mpv-shot0002.jpg (18.61 KiB) Viewed 3845 times

Bla1.mkv.zip.zip

(183.07 KiB) Downloaded 105 times