Page 2 of 2
Re: Over two frames of lag in mouse movement
Posted: Tue Dec 07, 2021 2:54 pm
by 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.
Re: Over two frames of lag in mouse movement
Posted: Tue Dec 07, 2021 3:46 pm
by cloudberry
pgimeno wrote: ↑Tue Dec 07, 2021 2:54 pm
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.
Re: Over two frames of lag in mouse movement
Posted: Tue Dec 07, 2021 5:29 pm
by 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 3528 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.
Re: Over two frames of lag in mouse movement
Posted: Tue Dec 07, 2021 7:04 pm
by 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.
Re: Over two frames of lag in mouse movement
Posted: Tue Dec 07, 2021 7:25 pm
by 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.
Re: Over two frames of lag in mouse movement
Posted: Wed Dec 08, 2021 3:22 am
by BrotSagtMist
pgimeno wrote: ↑Tue Dec 07, 2021 5:29 pm
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 3475 times