logical cursor position lags visible cursor position.

[stolk]

The visual and logical positions of my mouse cursor are not the same. If I draw a software mouse at the location where imgui thinks it is, it gets quite visible:

Is this imgui, sokol, my setup, or just inevitable?

I added io->MouseDrawCursor = 1; to sokol/sokol_imgui.h in simgui_setup()

[floooh]

Yeah I see this lag too on all platforms. Don't know what to do about this TBH. As far as I'm aware the swapchain implementations in sokol_app.h are not doing anything stupid to introduce additional lag (but they are also not doing anything special to reduce lag, because I'm not aware of any such tricks, suggestions welcome though).

Maybe there is an accidential frame of latency between receiving input events from the window system and when those events are processed in ImGui, but as far as I'm aware I'm not doing anything stupid there either which would introduce additional lag.

Might be worth checking if the ImGui "reference demos" behave better in this regard. I'll have a look.

[floooh]

...it looks like in the official ImGui samples the lag is also there, but it seems to be slightly better (tested on Windows with the D3D11 example in here):

https://github.com/ocornut/imgui/tree/master/examples

I'll have a look what this is doing differently.

[floooh]

Ok, the ImGui DX11 sample does one thing differently: the mouse position is polled instead of obtained via WM_MOUSEMOVE:

https://github.com/ocornut/imgui/blob/047d4c4500fc08b64d800eceae9951fc01c0a78b/backends/imgui_impl_win32.cpp#L160-L166

Swapchain setup, vsync, and general frame structure are otherwise identical.

I'll tinker around a bit with this and see if this leads to a similar improvement (at least on Windows). If yes I'll think about adding this sort of mouse polling to sokol_app.h too, or maybe I'll stumble over a few other simple fixes to generally reduce the mouse lag, so far I haven't spent much thought on this.

OTH, the lag in the official ImGui example is just very slightly reduced, but not at all "eliminated", but every little improvement counts I guess...

[floooh]

PS: what system are you actually on? I just noticed that your mouse pointer looks more like Mac :D I need to do the same investigation there.

[floooh]

...another random observation, switching off vsync makes a dramatic difference, but that's probably too wasteful...

I'll try to set aside some time to tinker with different ideas (for instance: vsync off and render only from within WM_MOUSEMOVE and other input events)...

Not a general solution, but maybe a combination of such tricks could lead to a special "low-latency-mode for UI applications" in sokol_app.h, vs a "game mode" etc...

PS: the "switch off vsync and render from within WM_MOUSEMOVE" looks very good, much better than even in the official ImGui examples. It'll be a while until I get around to do something about this "cleanly", I'll write a reminder ticket for now. The same issue has come quite a few times already, so I guess it's one of the next "big things" to work on.

[stolk]

...another random observation, switching off vsync makes a dramatic difference, but that's probably too wasteful...

Yes. A hand full of frames lag hardly matters if you render at 1000+ fps, but at 60 hz frames, it is a lot.

I also understand that ubuntu window manager stops compositing when full screen, but I read sokol does not have a fullscreen toggle, is that still the case?

[stolk]

PS: what system are you actually on? I just noticed that your mouse pointer looks more like Mac :D I need to do the same investigation there.

Ubuntu

[meshula]

Apple's "ProMotion" on iPad throttles all the way up to 120hz when you're interacting with the Pencil, but falls back dramatically if nothing's going on; so there's a nice existence proof that rendering in response to interaction feels good. (there's other tricks going on to improve the impression of responsiveness, but they're outside the scope.)

[floooh]

but I read sokol does not have a fullscreen toggle, is that still the case?

sokol_app.h has a toggle-fullscreen feature now, but doesn't support switching the display mode. On Windows it's simply a borderless window at the current desktop resolution, on X11 it's implemented with NET_WM_STATE_FULLSCREEN (not sure if this toggles the "fast path" in the window manager though):

https://github.com/floooh/sokol/blob/master/sokol_app.h#L9195-L9214

[stolk]

but I read sokol does not have a fullscreen toggle, is that still the case?

sokol_app.h has a toggle-fullscreen feature now, but doesn't support switching the display mode. On Windows it's simply a borderless window at the current desktop resolution, on X11 it's implemented with NET_WM_STATE_FULLSCREEN (not sure if this toggles the "fast path" in the window manager though):

https://github.com/floooh/sokol/blob/master/sokol_app.h#L9195-L9214

Thanks! Very useful feature indeed.

I can confirm that when I make the window full screen, I get the fast path.

I use nvidia-settings tool, to enable a visual indicator that tells you whether a window swaps with blitting or flipping, and only when full screen, it shows it is flipping. When windowed, it is blitting.

Full screen, I still see lag, but it's hard to quantify. I can't tell if it is the same, or a little less than when windowed. It is roughly of the same order, though.

[floooh]

Note: apart from a whole bunch of D3D11/DXGI improvements, frame latency on Windows has also been reduced dramatically in this commit:

https://github.com/floooh/sokol/commit/8c179166fce56d28bfab472115ce937235471e76

(I wasn't aware that DXGI's default config adds 3 frames of latency)

[eleriaqueen]

Hello, I'm on an Arch-based system with XFCE and I am experiencing the same kind of lag as shown in the original post when running the demo app.

A user seems to have found a partial solution. https://github.com/ocornut/imgui/issues/1805#issuecomment-1195617136