| Summary: | The brush resize feature (Shift-Drag) brings even a fast system to unusable stutter. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | JenyaYQ <jenya__> |
| Component: | Tools | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | dimula73, halla, jenya__ |
| Priority: | NOR | ||
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Chakra | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
[i]update[/i] compiled latest VC library 0.7 and recompiled the calligra from git a few minutes ago and there is a slight but noticeable improvement on the speed when resizing normal brushes but not with smear/dulling type brushes, they are still extremely slow on resize. I compiled latest VC library 0.7 and recompiled the calligra from git a few minutes ago and there is a slight but noticeable improvement on the speed when resizing normal brushes but not with smear/dulling type brushes, they are still extremely slow on resize. Hi, Thanks for your report. Especially with the dulling brush, I can reproduce the slowdown indeed. I solved this problem by resetting the brush to default setting and reconstructing it again. There must have been some legacy settings that caused this. All is fine now in the current alpha version. As for the following - - " ...I think that there is also a UI design problem with the feedback of the outline - the speed of the pen and the speed with which brush outline is growing while resizing is counter-intuitive and disproportionate. While it might seem a minor nuisance, if you do it every few seconds it starts to be a problem. The speed also varies according to zoom levels but why? From the UI design perspective - why should it be different on different zoom levels? It would be much more intuitive if the size of the outline followed my pen exactly regardless of the zoom level." - it definitely better and faster now (maybe it's the fact that I'm on VC 0.7.70, not sure) but it could be better still. hm, but we still ship that brush by default. Git commit 3bf294dfffa5969989dbee3b9182e68f6c4baa78 by Dmitry Kazakov. Committed on 08/05/2013 at 15:43. Pushed by dkazakov into branch 'master'. Fixed high CPU load when changing brush size with Shift-gesture Now it can update not more often than 25 times per second According to the measurements it allows us make about 80% less calculations. I don't close the bug because of the second part (scaling). Need to discuss it with Timothee and David. M +26 -2 krita/ui/tool/kis_tool.cc M +1 -0 krita/ui/tool/kis_tool.h M +1 -2 krita/ui/tool/kis_tool_freehand.cc http://commits.kde.org/calligra/3bf294dfffa5969989dbee3b9182e68f6c4baa78 The first part of the bug is now fixed. I really not sure about the fact that we should not zoom the gesture. If we don't zoom, working on zoomed-in images (>200%) is almost impossible. Animtim tested the gesture without scaling and said it is not very convenient. So I will close this bug, because the main problem of it is fixed. Git commit 755c9aa4218c33f10c27b21e5cda220adef3a45a by Dmitry Kazakov. Committed on 08/05/2013 at 15:43. Pushed by dkazakov into branch 'calligra/2.7'. Fixed high CPU load when changing brush size with Shift-gesture Now it can update not more often than 25 times per second According to the measurements it allows us make about 80% less calculations. I don't close the bug because of the second part (scaling). Need to discuss it with Timothee and David. M +26 -2 krita/ui/tool/kis_tool.cc M +1 -0 krita/ui/tool/kis_tool.h M +1 -2 krita/ui/tool/kis_tool_freehand.cc http://commits.kde.org/calligra/755c9aa4218c33f10c27b21e5cda220adef3a45a Spasibo Dima! Boud pointed out a solution in the forums earlier - just resetting the trouble-brush to default on newer versions of krita and rebuilding it from scratch solved it. I'm eager to see what you changes did.... Thank you again! *your Again, I was just reading my original comment on the scaling issue. Just to be clear - it's not so bad as it is, however what is a little confusing is that the speed with which the brush is scaling is in a weird dependance/lock to the current zoom level of the image. If, for example, I'm on 40% zoom then the scaling is noticeably slower. it's not laggy in this case, it's slower - a bit like trying to rotate a larger cog wheel with a smaller one.... ideally the scaling speed should be guided precisely by the movement/accelaration of the pen and ideally be independent of the current zoom level. I hope this helps. Also, it would really be awesome if the resizing circle or ellipse would be filled with current color showing not only the color & opacity while resizing but also give more information about the form of the brush and the softness of it's edges... maybe even show the rotation of the pen. That would be really useful. Git commit caf50787ecb0ad8406c9f510567b6194b393793c by Siddharth Sharma, on behalf of Dmitry Kazakov. Committed on 08/05/2013 at 15:43. Pushed by siddharthsharma into branch 'krita-psd-plugin-siddharth'. Fixed high CPU load when changing brush size with Shift-gesture Now it can update not more often than 25 times per second According to the measurements it allows us make about 80% less calculations. I don't close the bug because of the second part (scaling). Need to discuss it with Timothee and David. M +26 -2 krita/ui/tool/kis_tool.cc M +1 -0 krita/ui/tool/kis_tool.h M +1 -2 krita/ui/tool/kis_tool_freehand.cc http://commits.kde.org/calligra/caf50787ecb0ad8406c9f510567b6194b393793c Still there are reports that in some circumstances the Shift+Gesture brush resizing is very slow. It happens not always, but from time to time. One observation is that it happens after many 'resizing's done. Probably, some memory leak? The bug should be fixed after merge b0a4fcd58253a7e0819398b8daf3a06ee6918e1f |
Unfortunately the brush resizing issue got noticeably worse with latest git versions I tried to get rid of this problem by compiling from sources once a week for the past one and a half month or so but this problem persists. While resizing the standard round brushes (and their variants) is bearable even if laggy, resizing the dulling type brushes brings my otherwise fast system to such a stutter that I have to stop moving my pen until it finishes. There is something seriously wrong with this. I already tried it with and without nvidia drivers on different KDE Versions with different settings (with and without V Sync and other things) .... nothing seems to affect this in any positive way. I had similar problem with the official releases of Krita (and written in detail about this on this forum)but they were not as severe. I'm on Linux (Chakra Linux) with latest updates and latest Nvidia drivers. (have two separate systems with nouveau and nvidia drivers and its the same on both.) I thought I should also point out that It's really remarkable that while having these problems painting itself is really fast even on huge 8k 10k images with layers and the rest. Reproducible: Always Steps to Reproduce: "Everything is in Details." //Jenya (2013 C.E.) Actual Results: Yes, they are. Expected Results: No. This should probably filed separately but maybe this is just a part of the same problem.... I think that there is also a UI design problem with the appearance of the outline - the speed of the pen and the speed with which brush outline is growing while resizing is counter-intuitive and disproportionate. While it might seem a minor nuisance, if you do it every few seconds it starts to be a problem. The speed also varies according to zoom levels but why? From the UI design perspective - why should it be different on different zoom levels? I understand that there are technical reasons for the way it is right now but it shouldn't be the reason for not changing it. :) I hope that makes sense... It would be much more intuitive if the size of the outline followed my pen exactly regardless of the zoom level.