| Summary: | Brush strokes terminate slowly after a prolonged drawing session | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Neviril <nevineviril> |
| Component: | OpenGL Canvas | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 8172635, dimula73, gremriel, halla, lempikq, matt.coudert, spikestheraccon, tamtamy.tymona |
| Priority: | NOR | Keywords: | regression, release_blocker |
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Neviril
2019-05-30 22:10:33 UTC
https://forum.kde.org/viewtopic.php?f=139&t=160997&p=418045#p418045 suggests that it's actually a leak in the brush smoothing code. If it can be of any help, I always use "None" brush smoothing in tool option (rationale: under Windows 10 the Wacom pen tablet driver already performs significant stroke smoothing compared to the Linux driver). It could still be something related with pen tablet handling though, as the issue appears to occurs more easily after drawing many short and fast brush strokes in quick succession. I have the same problem, too. OS: Windows 10. Some additional information: - Switching between OpenGl and Angle (without restarting Krita) temporarily fixes it. - The first time I encountered this bug in 4.2.0 beta. - The last version I used before (git 8130f8d) doesn't have this problem. From my testing, krita-nightly-x64-v4.2.0-HDR-307-g96b04eda2b is the last version that does not has the lag. same problem here. Widows 10 / Krita 4.2 (the beta version too). When happening, i go to Settings / general / cursor and untick "while painting > use effective outline size". That done, i can paint for hours without lag. but it happen again sometimes in new sessions. if it's helpfull : poeple seems to found solutions for this issue by changing something in settings (change renderer or desactivate canvas graphic acceleration...) (In reply to Gremriel from comment #4) > From my testing, krita-nightly-x64-v4.2.0-HDR-307-g96b04eda2b is the last > version that does not has the lag. Hi, Gemriel! Do you have information about which version is the first having this issue? Like, what is the next nightly you have/tested? Git commit 69f91f701fd9ae045d33ae6baea9da98485c8688 by Dmitry Kazakov. Committed on 03/06/2019 at 09:35. Pushed by dkazakov into branch 'master'. Make KisSafeNodeProjectionStore actually reuse the projection Without any image present, the store will just drop the projection without any reusing. It may cause small slowdowns in the beginning of the stroke and (theoretically) memory fragmentation on Windows. I'm not sure if it actually the reason of the 408133, so we need a confirmation from the reporter first. M +2 -0 libs/image/kis_layer.cc M +1 -0 libs/image/kis_mask.cc https://invent.kde.org/kde/krita/commit/69f91f701fd9ae045d33ae6baea9da98485c8688 Dmitry, krita-nightly-x64-v4.2.0-HDR-307-g96b04eda2b is the last version that does not have this lag, everything after that does. The next version is 312 Hi, All! Could you please test if this build fixes the problem? It includes the commit I linked above: https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/lastSuccessfulBuild/artifact/krita-nightly-x64-v4.2.0-beta-136-g71af6ece75.zip Just finished testing 4.3.0-prealpha (git 71af6ec) on Windows 10-64bit 1903 with a drawing session composed of mainly fast brush strokes. The latest build does *not* solve the problem for me. After a while (in the order of minutes) I observe the same issue I initially reported and brush strokes over time get increasingly slowly terminated when the pen is lifted. Closing and reopening the image, even without closing the entire Krita application, appears to temporarily solve the issue, as others have pointed out. However selecting a different renderer (ANGLE instead of OpenGL) while the program is active (i.e. without restarting it) does not seem to solve it for me. (In reply to Neviril from comment #11) > The latest build does *not* solve the problem for me. After a while (in the > order of minutes) I observe the same issue I initially reported and brush > strokes over time get increasingly slowly terminated when the pen is lifted. Thank you for testing! I'll continue investigation then... This was mentioned in the forum: the undo stack going to infinity https://forum.kde.org/viewtopic.php?f=139&t=160997&p=418206#p418206 I tested the infinite undo history with undo set to 20: krita-nightly-x64-v4.2.0-HDR-298-g8f8660a2ea: works as expected krita-nightly-x64-v4.2.0-HDR-307-g96b04eda2b: works as expected krita-nightly-x64-v4.2.0-HDR-312-g0bb8b52570: works as expected krita-nightly-x64-v4.2.0-HDR-324-g81407392c7: infinite undo stack krita-nightly-x64-v4.2.0-HDR-328-g0a552f7b72: infinite undo stack krita-nightly-x64-v4.2.0-HDR-331-g199cd9f521: infinite undo stack. Not sure if this is related, but it falls within the builds I originally noticed this lag, although I thought 307 and 312 did not have this lag. Git commit 892eb03006cd92e7cd6ed56c4ba81d5f1ec9924b by Dmitry Kazakov. Committed on 04/06/2019 at 10:32. Pushed by dkazakov into branch 'master'. Fix infinite undo stack It might be possible that it was the reason of the slowdown bug, but it needs to be checked. Related: bug 408255 M +5 -2 libs/ui/KisDocument.cpp https://invent.kde.org/kde/krita/commit/892eb03006cd92e7cd6ed56c4ba81d5f1ec9924b Hi, Neviril and Gemriel! Could you please check this package if it fixes the problem? https://yadi.sk/d/XCSn_kTQVEhs-A Win 10 with Krita 4.2.0, latest drivers to everythign I can tell. It happens to me to. If I press "empty" in the "Undo History" after a long slow painful undo of history (boy it's so sluggish I can make a tea at that time) it clears everything and brushes more or less get back to their regular performance, so it might be connected to history in some way? If anything needed fro mme such as logs or something let me know I'm willing to try what you need for testing purposes as long as you provide clear instructions for me ;-). Have a nice day. Viktor, Is that with the build of krita Dmitry linked to above, or with the regular release? I've been painting and drawing with Dmitry's build for 2 hours now, and I don't see any noticeable lag. (In reply to Boudewijn Rempt from comment #17) > Viktor, Is that with the build of krita Dmitry linked to above, or with the > regular release? My bad I have some problems with KDE right now, I should have mentioned it's the regular release for win 10 64-bit. Hi, Viktor! Could you please test this package? It seems like it fixes the problem for Gremriel: https://yadi.sk/d/XCSn_kTQVEhs-A (In reply to Dmitry Kazakov from comment #20) > Hi, Viktor! > > Could you please test this package? It seems like it fixes the problem for > Gremriel: > > https://yadi.sk/d/XCSn_kTQVEhs-A I've been using it since my last reply and so far it works great. Is it stable in other aspects or should I not keep this as my regular for now? I'll give it a longer sessions later to see if I manage to get it broken again ;0. thx Yes, this is so close to 4.2.0 still that you should be safe in using this for work. Two confirmations -- let's close the bug. Git commit f5bfb54bce0980cf55518ab0486ca01b32113219 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 04/06/2019 at 15:19. Pushed by rempt into branch 'krita/4.2'. Make KisSafeNodeProjectionStore actually reuse the projection Without any image present, the store will just drop the projection without any reusing. It may cause small slowdowns in the beginning of the stroke and (theoretically) memory fragmentation on Windows. I'm not sure if it actually the reason of the 408133, so we need a confirmation from the reporter first. M +2 -0 libs/image/kis_layer.cc M +1 -0 libs/image/kis_mask.cc https://invent.kde.org/kde/krita/commit/f5bfb54bce0980cf55518ab0486ca01b32113219 Git commit a004a2ba86ef152ce5fc44d6d8f4db5b81942509 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 04/06/2019 at 15:21. Pushed by rempt into branch 'krita/4.2'. Fix infinite undo stack It might be possible that it was the reason of the slowdown bug, but it needs to be checked. Related: bug 408255 M +5 -2 libs/ui/KisDocument.cpp https://invent.kde.org/kde/krita/commit/a004a2ba86ef152ce5fc44d6d8f4db5b81942509 After testing Dmitry's build for a while I'm confident that the latest changes solved the issue I initially reported. |