Created attachment 189696 [details] the lag in video SUMMARY a lag appear in the cursor display when switching to previous brush (with shortcut). The cursor seems to be “stuck” waiting for a refresh of the canva… but you can paint with the new brush, just the cursor and outline are not update instantly (in the previous version, it is instant) STEPS TO REPRODUCE 1. choose a second brush 2. move the stylus over the canvas (ghost circles over the canvas) 3. press the shortcut to switch to previous brush... OBSERVED RESULT the cursor lagging to refresh, jumping to another spot EXPECTED RESULT the cursor update instantly SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 189697 [details] v5-2-15 with no lag
5.3.0 beta1 and beta2 have the lag. The cursor act like before in version 5.6 beta2. No problem on the 5.2.16 release
While I can reproduce with 5.3 and the nightlies, it isn't really lag, but rather that changing the cursor delays more now. There's been only a few changes to the outline: 1. The hi-dpi fix, but that couldn't have been it, as that only activates on hi-dpi displays (https://invent.kde.org/graphics/krita/-/merge_requests/2024) 2. A speed-up fix. That one tries to cache some stuff in other to get 10fps more speed (https://invent.kde.org/graphics/krita/-/merge_requests/2631) 3. A bounding box fix, also unlikely, as it is in 5.2.16 (https://invent.kde.org/graphics/krita/-/merge_requests/2456)
Hi, Mako! Could you check if the issue happens only with one specific brush "mako-dg-main" or it also happens with brushes from the default set? If it is specific to one brush, could you please send this brush to me? PS: I cannot reproduce this issue here, neither on Linux, nor on Windows.
uhm, another data point: I can only reproduce on linux with a mouse, but not with the stylus.
(In reply to Dmitry Kazakov from comment #4) > Hi, Mako! > > Could you check if the issue happens only with one specific brush > "mako-dg-main" or it also happens with brushes from the default set? > > If it is specific to one brush, could you please send this brush to me? > > PS: > I cannot reproduce this issue here, neither on Linux, nor on Windows. Hi, yes it also happens with brushes from the default set. If i remember correctly, i've tried with a clean install and the problem was present (both with openGL and Angle). i've this issue with both stylus and mouse. tell me if you need more infos...
I've just tested this on the latest nightly on Windows 11, and I can't reproduce this issue at all. I tested both mouse/trackpad and my laptop's tablet pen, but switching was seamless.
(In reply to Emmet O'Neill from comment #7) > I've just tested this on the latest nightly on Windows 11, and I can't > reproduce this issue at all. I tested both mouse/trackpad and my laptop's > tablet pen, but switching was seamless. Are the nightlies available somewhere? i can test on my side if you want.
Hi, Mako! Here is the link with the latest nightlies for 5.3.0: https://cdn.kde.org/ci-builds/graphics/krita/master/windows-qt5/ And this one is for 6.0.0: https://cdn.kde.org/ci-builds/graphics/krita/master/windows/
Hi, Mako! Do you have any custom plugins/dockers enabled? E.g. the recorder docker? I'm afraid, I cannot reproduce the problem here :( Preset switching works fine in both, Qt5 and Qt6 versions of Krita with both, mouse and tablet pointer device.
(In reply to Dmitry Kazakov from comment #10) > Hi, Mako! > > Do you have any custom plugins/dockers enabled? E.g. the recorder docker? > > I'm afraid, I cannot reproduce the problem here :( Preset switching works > fine in both, Qt5 and Qt6 versions of Krita with both, mouse and tablet > pointer device. Hi Dmitry, Thanks for the link, infortunatly i have the same issue with the nightly (as you can see on the attachement). i tried with a fresh created "roaming\krita" folder and it is the same. As for plugins, it is a fresh roaming so i think it s default config, i closed the recorder docker but i can't disable it as it's not listed in the settings... If it helps, i've noticed that if the krita window is not focused, when i came back to krita, the first stroke seems to act the same (with a delay) and there is no problem with the Qt6 version
Created attachment 190734 [details] test with nightly
🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information.
Hi Dmitry, i think i've found the origin of the problem. i notice a delay when i select a brush presset that may be the origin of the lag on the canvas when switching brush. In the new attachement you can see a delay between the click (yellow circle) and the selection of the presset. There is no delay in the Qt6 version
Created attachment 190958 [details] Selecting brush presset
Hi, Mako! How many brush bundles you have? Could you try removing everything from your resources folder (or better move to a safe place) and then start Krita from scratch? It looks like the problem in rendering preview of all the resources available, that might be related to the database access
(In reply to Dmitry Kazakov from comment #16) > Hi, Mako! > > How many brush bundles you have? Could you try removing everything from > your resources folder (or better move to a safe place) and then start Krita > from scratch? It looks like the problem in rendering preview of all the > resources available, that might be related to the database access It's the same with a fresh install, in 5.3 there is a delay when changing brush preset, 6.0 no problem in this area. when drawing a line and use the shortcut the switch to previous preset without losing the canvas contact, there is a noticable delay before the line and the cursor appears
Created attachment 190961 [details] delay
Git commit 3391d892b69f6f139dffec30e20701b215dd7211 by Dmitry Kazakov. Committed on 26/03/2026 at 14:34. Pushed by dkazakov into branch 'master'. Fix accessibility-induced problems on Windows The QML-based tooltips caused too many updates of the accessibility object name, so the system got just drowned in them. Related: bug 512694, bug 515820 M +1 -1 ext_qt/CMakeLists.txt https://invent.kde.org/packaging/krita-deps-management/-/commit/3391d892b69f6f139dffec30e20701b215dd7211
Git commit b7adcdc551cd47c79f59403ba0a68a7a73b76e1c by Dmitry Kazakov. Committed on 27/03/2026 at 09:02. Pushed by dkazakov into branch 'transition.now/qt6'. [qt][win] Add a switch to disable accessibility on Windows Related: bug 512694, bug 515820 M +1 -1 ext_qt/CMakeLists.txt https://invent.kde.org/packaging/krita-deps-management/-/commit/b7adcdc551cd47c79f59403ba0a68a7a73b76e1c
Git commit 8e132683450445b0aed4f6a955a5fc8c0df19c79 by Dmitry Kazakov. Committed on 31/03/2026 at 11:45. Pushed by dkazakov into branch 'transition.now/win-clang21'. Fix accessibility-induced problems on Windows The QML-based tooltips caused too many updates of the accessibility object name, so the system got just drowned in them. Related: bug 512694, bug 515820 M +1 -1 ext_qt/CMakeLists.txt https://invent.kde.org/packaging/krita-deps-management/-/commit/8e132683450445b0aed4f6a955a5fc8c0df19c79