At some indeterminable point point while working on an image, something starts interrupting strokes for a fraction of a second, approximately every second. The problem can be fixed temporarily by flattening the layers or restarting Krita. This occurs on both a desktop and Surface Pro 4 running Windows 10 64 bit. Reproducible: Sometimes
Can you check what the memory usage popup says when that happens?
Of course, now that I actually want it to happen, I'm having a hard time reproducing it (typical!). I was doing a lot of editing and testing presets at the time so maybe it was something I was doing related to that that was triggering it. It's doing it subtly on the SP4 at the moment though, here are the stats: Image size: 668.9M Memory used: 837.1M / 4.0G image data: 756.1M / 3.9G pool: 81.0M / 81.0M undo data: 47.9M Swap used: 2.1G I'll report back if the behaviour becomes more overt.
No sooner had I posted that comment than the more overt behaviour returned (typical!), this time when I loaded a slightly larger image with a few more layers. SP4: Image size: 1.6G Memory used: 1.3G / 4.0G image data: 1.2G / 3.9G pool: 81.0M / 81.0M undo data: 17.5M Swap used: 17.5M Desktop: Image size: 1.6G Memory used: 1.1G / 4.0G image data: 1.1G / 3.9G pool: 81.0M / 81.0M undo 24M Swap used: 114.7M It looks to be always reproducible on that particular image. Neither 2.9.9 nor 3.0 alpha 1 exhibit this issue with the same image.
Hm, I'm wondering if https://bugs.kde.org/show_bug.cgi?id=363320 isn't related. Could you make the image with which it's reproduce available so I can compare it to Camille's image?
https://www.dropbox.com/s/iuwcr95vvsrlgvf/stroke_pauses.zip?dl=0 Drawing on layer 1 with any brush should produce the effect. The original also had this problem on layer 5 and some of the other layers to a lesser extent, until I cleared the layers of any imagery. Does that give any clues?
Yes, if it's dependent on which layer you draw on, I'm pretty sure it's the same issue as 363320. I already made a phabricator task for that bug, so let's close this one as a duplicate. *** This bug has been marked as a duplicate of bug 363320 ***
Git commit bd46e0aa30c5fded9da44566fcd35f1335a550d1 by Dmitry Kazakov. Committed on 24/05/2016 at 10:19. Pushed by dkazakov into branch 'master'. Remove amortizing from the amortizeExactBounds() Its worst-case time may be higher than 300ms, which is unacceptable for the painter. So the proper solution would be to implement a special stroke that walks through all the layers and 1) Purges all the default pixel tiles using KisPaintDevice::purgeDefaultPixels() 2) Calls exactBounds() for every device to update the caches Fixes T2565 Fixes T2543 Related: bug 363320 M +7 -11 libs/image/kis_paint_device_cache.h http://commits.kde.org/krita/bd46e0aa30c5fded9da44566fcd35f1335a550d1