The shift drag brush resize is slower in recent git builds. Dmitry told that this may be related to the HUD work. Resizing a brush from 0 to 1000 takes two or three swipes, this hinders a smooth painting experience and is somewhat cumbersome. I have already made a task on phabricator at dmitry's request here it is -> https://phabricator.kde.org/T3406 Reproducible: Always
Still happens with current master.
Git commit 662ecc874f61ea5da34c66b5986a9a7fb36a6836 by Dmitry Kazakov. Committed on 12/08/2016 at 12:26. Pushed by dkazakov into branch 'master'. Fix the algorithm of the calculation of the Shift+Gesture scale Now it takes the screen size into account M +20 -12 libs/ui/tool/kis_tool_freehand.cc http://commits.kde.org/krita/662ecc874f61ea5da34c66b5986a9a7fb36a6836
Should this be fixed in 3.0.1 beta? if so, the problem still persist on W10. Seems a little less "choppy" than previous alphas, but still there.
Can confirm this. This bug is still present in the current beta build.
See https://phabricator.kde.org/T3520 -- I'm pretty sure this commit is in the windows build, so there's still something wrong.
Git commit dc8ae57fbad42f286c3250ec24cf3fab11aa2315 by Dmitry Kazakov. Committed on 05/09/2016 at 14:23. Pushed by dkazakov into branch 'master'. Fix slowdown when doing Shift+Drag resizing gesture This patch implements a concept of "sequence number" for KisPaintOpSettings objects. This "number" changes every time the properties change, therefore we can track if the property has been changed or not in the external code. Fixes T3520 M +6 -1 libs/image/brushengine/kis_paintop_config_widget.cpp M +1 -0 libs/image/brushengine/kis_paintop_config_widget.h M +2 -1 libs/image/brushengine/kis_paintop_settings.cpp M +16 -0 libs/image/kis_properties_configuration.cc M +13 -0 libs/image/kis_properties_configuration.h http://commits.kde.org/krita/dc8ae57fbad42f286c3250ec24cf3fab11aa2315
I apologize in advance for my ignorance, but does that last comment mean that it should be fixed on today's 3.0.1 build? Because the problem is still there.
It should be better than in the beta builds...
Unless it depends on some setting I might have overlooked, it isn't better than the beta builds here :(
I think that the lag Zafio may be referring to is different from the one Raghavendra originally reported (needing many pen strokes to move the size), and I don't know if the issues are related, I am experiencing some lag too kind of "jumpy" sizing. I made a video showing in real time what I am referring to. @Zafio, if you are referring to a lag like mine, let me know, may be we can report a bug or find if someone already did. https://drive.google.com/file/d/0B-cDWUXy4ZMmNEdmWlc1S18wY3c/view?usp=sharing
yes in newer builds from source i dont get lag in shift dragging like i reported initially. it is only jumping of the size that remains like Quiralta mentioned in the above comment.
@Quiralte @Boudewijn @Raghavendra for me the bug is also still present and feels the same as in the beta builds. But it seems really that the initial bug report may mean something slightly different. For me it is just a super laggy behavior(skippingmany inbetween sizes) and not easy to properly set the brush size via shift + drag.
@Quiralta That's it indeed!
@Zafio Good to know, the main guys are aware of it by now, thus for the time been I will just comment here instead of making another report.
*** Bug 368720 has been marked as a duplicate of this bug. ***