After a around an hour with the overview dock floating krita freezses. Steps to reproduce: 1. Overview Dock has to be visible and undocked from the toolbar just floating around 2. Draw a while. I'm using canvas sizes with 16 bit and at least 3000px on the longest side Krita will freezes after a while now the brush cursor will remain at some paint on canvas and the whole GUI will stop updating anything. Only exception your actual cursor, if you hover edges that are resizeable within the program (like the floating overview dock) it will change.
I cannot reproduce it on my Linux system. I created a 3000x3000px image, 16 bit (int) RGB color. 5 layers and drew for a while, but the system is running fine. Could you please provide more information: 1. What's the revision you are using? You can run git rev-parse HEAD to get it. 2. Which compiler (gcc or clang)? 3. What version of Qt are you using? 4. What linux distro? 5. Is it possible that you are running low on memory? Does "top" command show enough free memory and no swap is used. How much memory is krita using? 6. If you "dock" the overview docker, is krita still freezing? 7. If you close the overview docker, is it freezing?
Rev: 88a03cd3777a820db835f1e5eceb27346dd52d03 GCC: COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/lto-wrapper Ziel: x86_64-pc-linux-gnu Konfiguriert mit: ../gcc-4.9.3/configure --disable-libssp --enable-multilib --enable-version-specific-runtime-libs --enable-libmudflap --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3 --enable-libstdcxx-time --enable-__cxa_atexit --enable-clocale=gnu --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-lto --without-cloog --with-bugurl=http://bugs.funtoo.org --with-pkgversion='Funtoo 4.9.3-r3' --with-mpfr-include=/var/tmp/portage/sys-devel/gcc-4.9.3-r3/work/gcc-4.9.3/mpfr/src --with-mpfr-lib=/var/tmp/portage/sys-devel/gcc-4.9.3-r3/work/objdir/mpfr/src/.libs --enable-libgomp --build=x86_64-pc-linux-gnu --enable-libgomp --enable-languages=c,c++,fortran --disable-libgcj --disable-esp --disable-libsanitizer Thread-Modell: posix gcc-Version 4.9.3 (Funtoo 4.9.3-r3) QT: 5.6.1 Distro: Funtoo Memory: Never checked it but when I run out of memory the systems cursor would get slow very bad. 8GB RAM here but I'll check that next time. 6. Not tested yet 7. Nope could draw with it closed for multiple hours
Created attachment 100814 [details] My Krita ebuild
Freezes happen in docked mode too. total used free shared buff/cache available Mem: 7.7G 3.2G 253M 1.2G 4.3G 3.2G Swap: 5.2G 316K 5.2G Memory usage on krita looks good too: VIRT: 2843M RES: 985M SHR: 230M I was using a liquify/move brush from Deevads 8.1 brush kit, but I doubt that is the root of the problem. What I'm going to do now is using my nvidia card, maybe it's a bug with the intel module, which wouldn't surprise me.
Your configuration is similar to mine. I don't see how video driver could interact with overview widget. Are you comfortable debugging krita? Could you try running krita in a debugger. Build with debug information and run "gdb krita" When krita starts freezing, you can break in debugger and give "bt" command and then "c" to continue. Repeat a few times while krita is freezing. If you see that debugger often stops in the same places, could you post backtrace from bt command. It may point to the place where code is looping.
Took me a while to got it to freeze, like a hour now I had 2 images open, one reference and my drawing image and of course the overview. I was doing quick brush strokes with a soft brush. Going to attach the backtrace.
Created attachment 100853 [details] GDB Backtrace right after the freeze
Oh boy. An hour of work and all we get is a single hit inside overviewwidget and no function name. :) :). However, it may be quite informative. Looking at stuff up the stack, it looks like the call is coming from generateThumbnail function. If a new stroke comes, I cancel the stroke in process before starting the new one. However, you got execution stuck in waitForDone. This looks like a race condition somewhere. Yikes!
Pierre, I made a branch with a possible fix for this problem. Could you, please, test it. The branch with the changes is this one: https://phabricator.kde.org/diffusion/KRITA/browse/eingerman%252Foverviewdocker_bug_367901/
Tested it and drew for multiple ours (Even finished my painting) Looks like the build from your branch works. I got some minor slowdowns when I change brushes shortly after doing a stroke, I guess that's the point when this function triggers. I'm going to test it within the next days more so that I can confirm for sure that this fixes it.
This has been pushed to master now
Git commit 39fcfac8281d4d0bf100d4c15460fa2a2bc998ab by Dmitry Kazakov. Committed on 29/01/2022 at 11:47. Pushed by dkazakov into branch 'master'. Fix Krita discarding native threads every couple of seconds For years Krita has been spawning native threads carelessly. It happened because of the implementation of QThreadPool::waitForDone(), which discards threads on every successful call. We once had a patch for that (9c34fef3320983c8e0542363121035eab225cd29), but it has been reverted due to deadlock regressions it introduced. This patch adds a bit different implementation of the waiting strategy, so (I hope) it won't cause any deadlocks. Related: bug 360677 M +13 -0 libs/image/kis_update_job_item.h M +29 -4 libs/image/kis_updater_context.cpp M +7 -0 libs/image/kis_updater_context.h https://invent.kde.org/graphics/krita/commit/39fcfac8281d4d0bf100d4c15460fa2a2bc998ab
Git commit 8b9ac2512e9ec12f52411c86f299ea3550936a0a by Dmitry Kazakov. Committed on 23/02/2022 at 08:48. Pushed by dkazakov into branch 'krita/5.0'. Fix Krita discarding native threads every couple of seconds For years Krita has been spawning native threads carelessly. It happened because of the implementation of QThreadPool::waitForDone(), which discards threads on every successful call. We once had a patch for that (9c34fef3320983c8e0542363121035eab225cd29), but it has been reverted due to deadlock regressions it introduced. This patch adds a bit different implementation of the waiting strategy, so (I hope) it won't cause any deadlocks. Related: bug 360677 M +13 -0 libs/image/kis_update_job_item.h M +29 -4 libs/image/kis_updater_context.cpp M +7 -0 libs/image/kis_updater_context.h https://invent.kde.org/graphics/krita/commit/8b9ac2512e9ec12f52411c86f299ea3550936a0a