| Summary: | ctrl+click on canvas doesn't always disable eraser mode | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Rebecca Breu <rebecca> |
| Component: | General | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ahab.greybeard, dimula73, tamtamy.tymona |
| Priority: | NOR | Keywords: | regression |
| Version: | 4.2.8 | ||
| Target Milestone: | --- | ||
| Platform: | Debian stable | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/075e75ed79b6565679f3e1f0ee85d4148d282366 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | system info/debug log | ||
Setting to CONFIRMED
I can confirm this for the 4.2.8 appimage as described in the initial report. It seems random and infrequent but not rare.
It does not happen (as far as I can tell) with the Windows portable zip version 4.2.8 or the latest 4.3.0 prealpha portable zip running on Windows 10.
It happens all the time on the Dec 17th 4.3.0-prealpha (git d0ced0f) and later 4.3.0 prealpha appimages. (I don't have any earlier ones to test.)
It's when you Ctrl+click/tap on exactly the same colour that is already selected. If you pick a colour that has even +/-1 difference in the RGB value then erase mode switches off.
Also, if you use the stylus/mouse to do an erase stroke and then Ctrl+click/tap on the same colour, the erase mode switches off.
Also, if you do a Ctrl+click/tap again with less than about 0.5 seconds between clicks/taps, the erase mode switches off. Doing it more slowly leaves the erase mode still on.
This does not happen if you select the Colour Selector Tool and use that instead, UNLESS you uncheck the Update Color option in the Tool Options docker, in which case it does happen.
(The E key will still activate the erase mode and it will be indicated as such in the toolbar even though it's greyed out when the Color Selector Tool has been selected. After this, it becomes fully active again.)
SYSTEM INFORMATION:
Krita
Version: 4.3.0-prealpha (git d0ced0f)
Languages: en_GB, en, en, en_GB, en
Hidpi: true
Qt
Version (compiled): 5.12.5
Version (loaded): 5.12.5
OS Information
Build ABI: x86_64-little_endian-lp64
Build CPU: x86_64
CPU: x86_64
Kernel Type: linux
Kernel Version: 4.19.0-6-amd64
Pretty Productname: Debian GNU/Linux 10 (buster)
Product Type: debian
Product Version: 10
OpenGL Info
Vendor: "NVIDIA Corporation"
Renderer: "GeForce GTX 750 Ti/PCIe/SSE2"
Version: "4.6.0 NVIDIA 418.74"
Shading language: "4.60 NVIDIA"
Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile)
Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile)
Version: 4.6
Supports deprecated functions true
is OpenGL ES: false
QPA OpenGL Detection Info
supportsDesktopGL: true
supportsOpenGLES: true
isQtPreferOpenGLES: false
Hardware Information
GPU Acceleration: auto
Memory: 16039 Mb
Number of Cores: 8
Swap Location: /tmp
Current Settings
Current Swap Location: /tmp
Undo Enabled: 1
Undo Stack Limit: 18
Use OpenGL: 1
Use OpenGL Texture Buffer: 1
Use AMD Vectorization Workaround: 0
Canvas State: OPENGL_SUCCESS
Autosave Interval: 360
Use Backup Files: 1
Number of Backups Kept: 1
Backup File Suffix: ~
Backup Location: Same Folder as the File
Use Win8 Pointer Input: 0
Use RightMiddleTabletButton Workaround: 0
Levels of Detail Enabled: 0
Use Zip64: 0
I also get this issue on the 4.2.5 and 4.2.7.1b appimages, but not on the 4.1.7 appimage. I'm going to try fix my docker build and see if I can reproduce it there—that would give me a chance to bisect it. I can reproduce this in my compiled-in-docker build on current master. Interestingly enough, while I still didn't get this in the 4.1.7 appimage even once despite trying spending quite some time on it over several sessions, I do get it in my 4.1.7 compiled-in-docker build, albeit a lot less frequently than in more recent versions. So I guess this isn't just a matter of finding a bad commit between 4.1.7 and now, but rather an issue that seems to get more or less exposed depending on various circumstances, and which is hard to quantify, so I gave up on the bisecting idea. I've had another look at this. The 4.2.8 appimage now does it most of the time instead of rarely and the Ctrl+double-click no longer makes the eraser mode turn off. With the Dec22 4.3.0 prealpha appimage, it does it all the time. The Ctrl+double-click sometimes (not always) makes the eraser mode turn off. On my laptop running Debian 10, the 4.3.0 prealpha appimage does it most but not all of the time. In all situations, using the eraser now no longer makes the eraser mode turn off after the next Ctrl+click. It's very hard to quantify and examine. In my experience: - 4.2.9 works mostly fine, there are, very rarely, cases that it doesn't work (I would blame it on my tablet, tbh, if I haven't read here that it happens sometimes for you as well and that it just worsened with every new build) - 4.3.0 prealpha 3f0ff1a (December 28th?) - it switches or not, seems random, but it's working ~30-40% of times - 4.3.0 prealpha 030e384 (April 22th) - it *never* works correctly. Right now it never switches the eraser mode if the picked color is equal to the previous one. Hence I'm setting it to regression, because 4.2.9 works just fine for me (well, much *finer*). The difference in usage is huge. Linux Mint 19.3 with Cinnamon, I used appimages. I think my recent commit 40adc1626c9bc978c085f11d16892143be0d6757 made it stop working when the color doesn't change :) Git commit 6cd9eba4e414964b9147d045ac4765c078180ec7 by Dmitry Kazakov. Committed on 06/05/2020 at 21:25. Pushed by dkazakov into branch 'master'. Fix eraser mode to be reset when the same color is picked from the canvas This functionality was broken by the fix for not emitting resource change signal when the resource does not change (commit 40adc1626c9bc978c085f11d16892143be0d6757). Now the resource manager has one more signal --- resourceChangeAttempted(key, value). This signal is emitted before the actual resource change and it doesn't depend on whether the resource has changed or not (emitted in both the cases). M +2 -0 libs/flake/KoCanvasResourceProvider.cpp M +11 -0 libs/flake/KoCanvasResourceProvider.h M +20 -0 libs/flake/KoResourceManager_p.cpp M +4 -0 libs/flake/KoResourceManager_p.h M +11 -4 libs/ui/kis_paintop_box.cc M +1 -0 libs/ui/kis_paintop_box.h https://invent.kde.org/kde/krita/commit/6cd9eba4e414964b9147d045ac4765c078180ec7 Git commit 075e75ed79b6565679f3e1f0ee85d4148d282366 by Dmitry Kazakov. Committed on 06/05/2020 at 21:21. Pushed by rempt into branch 'krita/4.3'. Fix eraser mode to be reset when the same color is picked from the canvas This functionality was broken by the fix for not emitting resource change signal when the resource does not change (commit 40adc1626c9bc978c085f11d16892143be0d6757). Now the resource manager has one more signal --- resourceChangeAttempted(key, value). This signal is emitted before the actual resource change and it doesn't depend on whether the resource has changed or not (emitted in both the cases). M +2 -0 libs/flake/KoCanvasResourceProvider.cpp M +11 -0 libs/flake/KoCanvasResourceProvider.h M +20 -0 libs/flake/KoResourceManager_p.cpp M +4 -0 libs/flake/KoResourceManager_p.h M +11 -4 libs/ui/kis_paintop_box.cc M +1 -0 libs/ui/kis_paintop_box.h https://invent.kde.org/kde/krita/commit/075e75ed79b6565679f3e1f0ee85d4148d282366 |
Created attachment 124665 [details] system info/debug log SUMMARY Once in a while, when cltr+clicking on the canvas to pick a colour, the eraser mode doesn't reset. I'm not sure if there are steps to make this 100% reproducible, but my observations so far: 1. Only seems to happen when the colour I pick from the canvas is the same as the colour already selected 2. Doesn't seem to have anything to do with Gamut masks 3. Doesn't seem to have anything to do with layers 4. I only use my stylus (pen side) for this—not switching between input devices, not using the eraser side of the stylus I'm on the krita-4.2.8-x86_64.appimage STEPS TO REPRODUCE 1. Paint a big solid brush stroke with one colour 2. Switch to eraser mode with E 3. Ctrl+click on the brush stroke from step 1 so that you are picking the same colour you already have. You might need to repeat steps 2-3 a couple of times. OBSERVED RESULT Sometimes it switches eraser mode off, sometimes it doesn't. EXPECTED RESULT Should always switch eraser mode off