Created attachment 189252 [details] latency comparison video SUMMARY Krita 6 has a significantly higher latency by default for me compared to Krita 5. My primary monitor is 144Hz, my others are 60Hz. When krita is on a 60hz monitor it's very sluggish, but on the 144Hz monitor it's fine. Using the vblank_mode=0 env variable alleviates the lagginess on the 60hz monitors. Changing my primary monitor's refresh rate down to 60hz also seems to fix it instantly, even while Krita is running. (see attachment for a video taken on my 60hz monitor, showing the panning latency before and after adjusting the other monitor's refresh rate) Happens both with and without Canvas Graphics Acceleration checked. STEPS TO REPRODUCE 1. Have too multiple monitors with different refresh rates 2. Run krita 6.0 on one of the lower hz ones 3. I assume wayland is also important? OBSERVED RESULT program repainting seems very slow and lags far behind EXPECTED RESULT no laggier than krita 5 in the same scenario SOFTWARE/OS VERSIONS $ kinfo Operating System: Kubuntu 25.10 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.2 Kernel Version: 6.17.0-8-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: AMD Radeon RX 6600 ADDITIONAL INFORMATION
Hi, Stuff! Could you please perform a small test for me? 1) Run Krita with a special environment variable set: export QT_FRAME_RATE_OVERRIDE=60 krita 2) Then test on both sccreens In previous versions Krita was limited to 60FPS, it was hardcoded. But in 6.0 it looks for all the screens and uses **maximum FPS it can find**.
Created attachment 189504 [details] matrix of options on 60Hz tablet
Created attachment 189505 [details] QT_FRAME_RATE_OVERRIDE=60 on 144hz monitor
Yes, I did an experiment, the videos in the video grid were all taken on the 60HZ tablet monitor. It sure looks like the mixed refresh rate doesn't matter at all? Maybe I was confusing myself before, I'm certainly confused now. Subjectively everything at 144HZ looks good, though, even with QT_FRAME_RATE_OVERRIDE=60. That option doesn't seem to make a difference in this case, but I trust it's enabled because it prints the following: qt.widgets.painting: QWidgetRepaintManager: refresh rate has been overridden to 60 fps (detected display rate was: 143.882 fps) Also, when the 144Hz monitor is set to 60Hz it seems to have the same lag as the tablet, so I guess there's just a general delay in 6.0 that's less noticeable at 144HZ? i'm confusing myself again.
Git commit b9be7b8b2e0dde06897c371520f6be3561dbdf61 by Dmitry Kazakov. Committed on 23/02/2026 at 12:27. Pushed by dkazakov into branch 'transition.now/qt6'. [qt][xcb] Implement QT_GLX_SWAP_INTERVAL_SYNC_WORKAROUND Related: bug 516267 M +1 -1 ext_qt/CMakeLists.txt https://invent.kde.org/packaging/krita-deps-management/-/commit/b9be7b8b2e0dde06897c371520f6be3561dbdf61
Hi, Stuff! Could you please check what happens if you run Krita 6 under native Wayland protocol? QT_QPA_PLATFORM=wayland krita*.AppImage Do you still have the lag? PS: You can test on any released version of Krita 6, beta1 or beta2, it doesn't matter.
There's no lag with QT_QPA_PLATFORM=wayland :)
Then it should be the same bug as bug 516267 :) Please check tomorrows nightlies of master, i.e. Krita Next: https://cdn.kde.org/ci-builds/graphics/krita/master/linux/ It will have two fixes for that: one -- a workaround inside Qt for GLX backend, and a GUI switch in Krita settings to be able to switch into EGL backend.
Nightly 6.1.0-prealpha-bd6975bd38 has no lag and works great with zero configuration. Thank you!
Thanks a lot for testing! :)