| Summary: | Brush parameters mixes up when switch between Stylus and Eraser. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Tyson Tan <tysontanx> |
| Component: | Brush engines | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | dimula73, esdouzewa, halla, siebtzen |
| Priority: | NOR | Keywords: | release_blocker |
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/calligra/d7d768aba09499428bbc7766d00743d7764c67fe | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Tyson Tan
2013-10-22 13:56:36 UTC
Animtim confirms. Still present in master. You need to flip several times to see the weirdness. For me stylus->eraser->stylus->eraser will lead to Eraser Mode disabled. I've tried again, and I still cannot reproduce :-( Seen a similar problem on 2.8 Pre-Alpha, on Windows 7: http://www.youtube.com/watch?v=glL85gEaZS0&feature=youtu.be You can see that I use a small pencil, then switch to the soft eraser (by flipping my Intuos 3's stylus) which draws instead of erasing. When I raise the stylus' eraser and then touch the tablet again, the eraser works as it should. Please let me know if you'd rather have a separate bug as I'm on a different platform or if you need any clarification. *** Bug 330172 has been marked as a duplicate of this bug. *** It looks as if the signal that changes the composite op comes later than the user starts the next stroke. I cannot reproduce the real weirdness which I saw before, but still there is another bug: if you flip the pen too fast, your first stroke will be started before the composite op has been changed and you will paint instead of erasing. And yes it is applicable to the first stroke after the flip only. Ok, on Windows the bug still persist. The main condition for a bug: 1) Paint with one side of the pen 2) Leave the proximity 3) Flip the pen somewhere in the air 4) [very fast] Bring the pen into proximity and start painting. The composite op doesn't manage to change in time so the first stroke is done in old Composite Op. Also on Windows after several attempts to reproduce that Krita gets crazy when trying to paint with eraser and changes the composite op randomly. On Linux I didn't manage to make Krita crazy, probably, it is windows specific. So we have two bugs here: 1) Race condition on Composite Op when flipping the pen too fast (Linux + Windows) 2) Krita gets crazy in some time, by sticking to one specific tip of the pen. That results in Krita switching back to, say, Eraser of the pen as soon as you leave proximity with the Pen tip. That is is switches back to a specific tip when you leave proximity of the device. @Dimitry I happened to reproduce something similar to Comment 7 yesterday using build from 2.8 branch source. 1) Pen tip was assigned to default brush. 2) Pen eraser was assigned to "Basic Eraser" present. 3) I filpped my pen quite prequently. 4) Suddenly, I found I was drawing with "Basic Eraser" on the pen tip. And I was using a Trisquel GNU/Linux 6.0 (a Ubuntu 12.04 derivative), so I think this might not be Windows specific. Although comparing to the original state when I reported this bug, it has been improved somehow that I haven't see it for quite sometime. When I encountered this yesterday, I totally forgot I had reported this bug before. :b Git commit 36950b6e5f4a1340ec93f97d8384c1d430b4704f by Dmitry Kazakov. Committed on 02/02/2014 at 12:25. Pushed by dkazakov into branch 'master'. Fixed the half of the Pen/Eraser flip bug We should call the update slot explicitly when changing the paintop preset and do not rely on the widgets, which would also emit the update signal, but later. We can't wait for widgets because they use a deferring timer internally. Now it is left to fix the Windows-only problem. M +7 -0 krita/ui/kis_paintop_box.cc http://commits.kde.org/calligra/36950b6e5f4a1340ec93f97d8384c1d430b4704f The brush settings do not mix up on Windows now, but it still switches back to a random tip of the stylus when the stylus is outside the proximity. This prevents configuration of the stylus using the mouse. To reproduce the bug you need to switch windows with a stylus at least once. Git commit 6f7ac56db4b71f54cbd737a3f0781fd2c4676600 by Dmitry Kazakov. Committed on 02/02/2014 at 14:35. Pushed by dkazakov into branch 'master'. Don't eat WinTab Proximity packets from the WinTab's queue! Qt also needs these packets to issue the Enter/Leave events. So just use the *Peek variant of the function instead of *Get. M +5 -2 krita/ui/input/wintab/kis_tablet_support_win.cpp http://commits.kde.org/calligra/6f7ac56db4b71f54cbd737a3f0781fd2c4676600 Git commit ef2bcf8e3c27f58003089f87dcf829d48840139c by Dmitry Kazakov. Committed on 02/02/2014 at 12:25. Pushed by dkazakov into branch 'calligra/2.8'. Fixed the half of the Pen/Eraser flip bug We should call the update slot explicitly when changing the paintop preset and do not rely on the widgets, which would also emit the update signal, but later. We can't wait for widgets because they use a deferring timer internally. Now it is left to fix the Windows-only problem. M +7 -0 krita/ui/kis_paintop_box.cc http://commits.kde.org/calligra/ef2bcf8e3c27f58003089f87dcf829d48840139c Git commit d7d768aba09499428bbc7766d00743d7764c67fe by Dmitry Kazakov. Committed on 02/02/2014 at 14:35. Pushed by dkazakov into branch 'calligra/2.8'. Don't eat WinTab Proximity packets from the WinTab's queue! Qt also needs these packets to issue the Enter/Leave events. So just use the *Peek variant of the function instead of *Get. M +5 -2 krita/ui/input/wintab/kis_tablet_support_win.cpp http://commits.kde.org/calligra/d7d768aba09499428bbc7766d00743d7764c67fe |