Chong Kai Xiong

One additional clarification, I tested Tux Paint with --fullscreen=native. --fullscreen=yes on the other hand lags with a flood of "discarding mouse motion event" messages. This seems to be a new problem and perhaps a separate issue. Because scale-to-fit is blocky and unpleasant looking on my 35-inch ultrawide, I do not use --fullscreen=yes and am not really bothered by this bug.

One additional clarification, I tested TuxPaint with --fullscreen=native. --fullscreen=yes on the other hand lags with a flood of "discarding mouse motion event" messages. This seems to be a new problem and perhaps a separate issue. Because scale-to-fit is blocky and unpleasant looking on my 35-inch ultrawide, I do not use --fullscreen=yes and am not really bothered by this bug.

Hey everyone, thanks for all that the hard work! I've done some testing and can confirm that the latest commit 90cc8d93 works for me. However, the true reason is an unexpected combination of two changes: SDL_RenderPresent() no longer waits on a VSync by default. I confirmed this by using SDL_SetRenderVSync(Renderer, 1) and measured the return of the VSync-induced lag. This is entirely down to some change in my environment which I'm unable to pinpoint. There are just too many factors involved: GNOME,...

Hey everyone, thanks for all that the hard work! I've done some testing and can confirm that the latest commit 90cc8d93 works for me. However, the true reason is an unexpected combination of two changes: SDL_RenderPresent() no longer waits on a VSync by default. I confirmed this by using SDL_SetRenderVSync(Renderer, 1) and measured the return of the VSync-induced lag. This is entirely down to some change in my environment which I'm unable to pinpoint. There are just too many factors involved: GNOME,...

Hey everyone, thanks for all that the hard work! I've done some testing and can confirm that the latest commit 90cc8d93 works for me. However true reason is an unexpected combination of two changes: SDL_RenderPresent() no longer waits on a VSync by default. I confirmed this by using SDL_SetRenderVSync(Renderer, 1) and measured the return of the VSync-induced lag. This is entirely down to some change in my environment which I'm unable to pinpoint. There are just too many factors involved: GNOME, SDL3,...

Hi William, I've tested the latest from master. The issue persists for me. Now it even seems to affect --fullscreen=yes. Pop-up dialogs take a while to show up as well. I'm currently on Bluefin 44 (Fedora-based) running GNOME 50.1 on Wayland. SDL versions: sdl2-compat 2.32.68 SDL3 3.4.10 Display settings: Resolution: 3440x1440 Refresh Rate: Variable (48-99.98 Hz) Tested with VRR on and off. If it matters, my mouse resolution is at 1600 dpi, with a polling rate set to 2000Hz.

Hi William, I've tested the latest from master. The issue persists for me. Now it even seems to affect --fullscreen=yes. Pop-up dialogs take a while to show up as well. I'm currently on Bluefin 44 (Fedora-based) running GNOME 50.1 on Wayland. SDL versions: sdl2-compat 2.32.68 SDL3 3.4.10 Display settings: Resolution: 3440x1440 Refresh Rate: Variable (48-99.98 Hz) Tested with VRR on and off. If it matters, my mouse resolution is at 1600 dpi, with a polling rate set to 2000Hz.

Hi, The report was based on my experience on both the Flatpak and git master (96a8cde5). Although I have a mouse running at 1000 DPI and high polling rate for gaming (first-person shooter), the issue has little to do with either. I've inserted SDL_GetTicks() into the code to measure the input (to display) latency and the results were extremely predictable, averaging around the display's refresh interval. When the refresh rate was set at 100Hz, the delay was 10ms. At 60Hz, it was around 15 to 17ms....