*** SUMMARY Starting a certain build version, Krita 5.3.0 prealpha and now Krita 5.3.0's first beta, is running with a UI extremely slow in almost all places. The only place that is seemingly not affected is the scratchpad. STEPS TO REPRODUCE 1. Open a document and create multiple layers, at least 3 or 4 2. highlight one layer or the other with the mouse left click 3. on the canvas, attempt to rapidly make fast strokes with a simple brush. The basic opacity or ink brush is fine OBSERVED RESULT Stutter, delays, or lags with all the operations described above. Major freeze with the rapid strokes on the canvas. Oddly enough, the scratchpad isn't affected by the lag and stutters/delays. EXPECTED RESULT No stutter or lag on the UI or the canvas. SOFTWARE/OS VERSIONS Windows 10 Pro ADDITIONAL INFORMATION CPU : Core-i7 3rd gen mobile GPU : Nvidia GT640 M
Can you identify which build it started at? (Or the last build that did not have this problem)
(In reply to wolthera from comment #1) > Can you identify which build it started at? (Or the last build that did not > have this problem) Last prealpha build I remember to not have this problem is build 9c6e268b, version 5.3.0.
Hi, Stephen! Could you please make a video of the problem? And could you also check if you have GPU Acceleration enabled in the settings?
Created attachment 189498 [details] krita 5.3.0 UI and general lag (In reply to Dmitry Kazakov from comment #3) > Hi, Stephen! > > Could you please make a video of the problem? > > And could you also check if you have GPU Acceleration enabled in the > settings? Greetings Dmitry. Check the video appended above.
(In reply to Dmitry Kazakov from comment #3) > Hi, Stephen! > > Could you please make a video of the problem? > > And could you also check if you have GPU Acceleration enabled in the > settings? I always use GPU Acceleration by the way. It was activated in the settings. But even if GPU Acceleration is turned off, all the UI shouldn't lag like this.
(In reply to Dmitry Kazakov from comment #3) > Hi, Stephen! > > Could you please make a video of the problem? > > And could you also check if you have GPU Acceleration enabled in the > settings? Update : after unticking and ticking "Canvas acceleration", the app crashes. No idea why.
Hi, Stephen! Could you check what exactly says the yellow label on the status bar of your Krita instance? It usually means that Krita doesn't have enough RAM. Which could basically explain why everything looks so slow...
(In reply to Dmitry Kazakov from comment #7) > Hi, Stephen! > > Could you check what exactly says the yellow label on the status bar of your > Krita instance? It usually means that Krita doesn't have enough RAM. Which > could basically explain why everything looks so slow... I do not think RAM is the issue. I mean, I am running the same config for older versions of Krita 5.3.0 And it runs fine there. Surely this beta update did not suddenly begin to consume more RAM, yes? Even when it turns red, it is never this slow. And like I said, the issue is about the UI in general. Even without opening a document, all is slow, as you click on the drop-down menu buttons on the Menu Bar and scroll through. It is very very slow. ( I give Krita 4GB of Memory limit RAM and 511 MB of swap )
Created attachment 189532 [details] description : status bar (In reply to Dmitry Kazakov from comment #7) > Hi, Stephen! > > Could you check what exactly says the yellow label on the status bar of your > Krita instance? It usually means that Krita doesn't have enough RAM. Which > could basically explain why everything looks so slow... File appended for the info.
Hi, Stephen! Could you please check two things? 1) Could you check if you have enough free memory at the OS level. Just check the status in the Tasks Manager, if Swap File is used. It seems like you have 8GiB in total, and that might be a really low amount for Windows 11. Perhaps you got some Windows update that installed you some Edge/Copilot things? 2) If that doesn't show anything, try removing (with a backup) all Krita settings in %APPDATA% and %LOCALAPPDATA%.
(In reply to Dmitry Kazakov from comment #10) > Hi, Stephen! > > Could you please check two things? > > 1) Could you check if you have enough free memory at the OS level. Just > check the status in the Tasks Manager, if Swap File is used. > > It seems like you have 8GiB in total, and that might be a really low amount > for Windows 11. Perhaps you got some Windows update that installed you some > Edge/Copilot things? > > 2) If that doesn't show anything, try removing (with a backup) all Krita > settings in %APPDATA% and %LOCALAPPDATA%. 1 ) Yes, I have enough RAM available. The swap file is not the problem here. Even when i open a brand new A4 document at 300ppi, with only 2 layers, Krita consumes at most 300 Megs for itself and my document( 33 Megs of RAM in actuality for the document itself ). Given that I have 12 Gigs of RAM, that's like consuming only 2% of my RAM. It is not much, really. Also I don't do windows updates for the sake of stability. I have disabled everything that makes updates automatic since I prefer the manual route. 2 ) I literally tried a brand new environment as suggested. Issue remains the same. Please remember that an older prealpha 5.3.0 version works without that UI lag issue. Also Krita 6.0.0 beta 1 doesn't have this UI lag problem either. Remember also that the scratchpad is not affected at all, however the items of the brush settings UI are affected.
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 516149 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 516149 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 516149 M +1 -1 ext_qt/CMakeLists.txt https://invent.kde.org/packaging/krita-deps-management/-/commit/8e132683450445b0aed4f6a955a5fc8c0df19c79