GNOME Bugzilla – Bug 771444
Tablet stylus misbehaves when crossing the edge of a dock in multi-window-mode
Last modified: 2017-09-01 09:50:10 UTC
In Multi-Window Mode, if you select a brush/paint tool and use the mouse, you can move the crosshairs and outline of the brush completely past the image frame (including the background), and back again. As long as the mouse isn't lifted, the brush reappears when you sweep back over the image. When using the stylus (Wacom bamboo) for painting, it seems as if the mouse is briefly activated when the stylus is moved past the edges of the image and/or image window frame. Then odd things happen: 1. Sometimes the brush outline gets stuck at the edge of the image, and then you have to lift the paint tool to continue painting. 2. There might be artifacts in the painted areas. The artifacts vary, but here is an example (the black bars happened all by themselves): http://ninedegreesbelow.com/bug-reports/gimp29/artifacting.jpg 3. The stylus paint tool settings might be switched over to the mouse paint tool settings, so the brush size might change, and the paint tool might switch from brush to airbrush, and so on. 4. If the Device Status Dialog is open, you can sometimes see a flicker as the device changes from the stylus to the mouse and back. 5. There might be lots of terminal warnings as follows: (gimp-2.9:7558): Gimp-Tools-CRITICAL **: gimp_tool_set_focus_display: assertion 'gimp_tool_control_is_active (tool->control) == FALSE' failed (gimp-2.9:7558): Gimp-Tools-CRITICAL **: gimp_tool_set_modifier_state: assertion 'gimp_tool_control_is_active (tool->control) == FALSE' failed (gimp-2.9:7558): Gimp-Tools-CRITICAL **: gimp_tool_oper_update: assertion 'gimp_tool_control_is_active (tool->control) == FALSE' failed Running GIMP using "--gtk-g-fatal-warnings" (whether under gdb or just using "gimp-2.9 --gtk-g-fatal-warnings") makes the terminal warnings disappear, but the other issues remain. So it doesn't seem possible to crash GIMP to generate a backtrace. If it's relevant, this is default GIMP from git, commit 0ecd936 updated this morning, starting with completely uninstalling GIMP (deleting the folders, too, to make sure nothing was left behind) and starting with ./autogen.sh. I'm running gentoo linux and using IceWM with the mouse focus set to "click to focus". The problem doesn't happen using Single Window Mode.
I confirm this under Fedora 23 + GNOME (so not OS/desktop related): - Happens only in MWM. - I get the warnings too. - When you open the device status dock, *sometimes* you can see the selected device flicker briefly when going over docks (not all the time, or else it's too fast for the GUI to show it). Same as Elle, warnings disappear when I run with --gtk-g-fatal-warnings making it harder to generate a backtrace.
Created attachment 335684 [details] [review] don't switch tool while painting This problem also explains the reports regarding the selection marching ants stopping to march and the undo list not including few strokes (try with a selection and look at the undo list when the tool switch happens) I tried to reproduce this problem with gtk3-port and could not, but I've noticed that gdk3 introduced new GdkAxisUse enum values making the string array 'axis_use_strings' https://git.gnome.org/browse/gimp/tree/app/widgets/gimpdeviceinfoeditor.c#n137 shorter than needed for many loops (it is necessary either to add strings for the new values or to write the loop like: for (i = GDK_AXIS_X; i <= GDK_AXIS_WHEEL; Gcc warns: >app/widgets/gimpdeviceinfoeditor.c|216 col 54| warning: iteration 6 invokes undefined behavior [-Waggressive-loop-optimizations] > const gchar *string = gettext (axis_use_strings[i]); > ~~~~~~~~~~~~~~~~^~~ and (at least having set LD_PRELOAD=libasan.so.3) opening the input device window crashes GIMP (it crashes also opening the foreground color chooser, but that's another problem). The attached quick hack seems to fix the problem in gimp-2.9 (in gtk3-port is probably unnecessary). Given the few tests I've done I don't know whether it breaks something else.
(In reply to Massimo from comment #2) > Created attachment 335684 [details] [review] [review] > don't switch tool while painting > > This problem also explains the reports regarding the selection marching ants > stopping to march and the undo list not including few strokes (try with > a selection and look at the undo list when the tool switch happens) I had noticed the marching ants sometimes stopping, or rather disappearing altogether as I set the "marching speed" to as high as possible so the ants don't actually march, and also the issue with undo sometimes missing items (I think not confined to just painting strokes), but didn't realize these other issues might be connected to the painting issue. > The attached quick hack seems to fix the problem in gimp-2.9 (in gtk3-port > is probably unnecessary). Given the few tests I've done I don't know whether > it breaks something else. I just applied the patch and it does eliminate the painting issue - yeah! If anything else seems to break (I'll probably be using GIMP a fair amount this weekend) I'll make a post.
Review of attachment 335684 [details] [review]: Well found. I'm wondering, should we not just ignore the event (return TRUE) when there is a device change during a motion grab?
(In reply to Jehan from comment #4) > Review of attachment 335684 [details] [review] [review]: > > Well found. I'm wondering, should we not just ignore the event (return TRUE) > when there is a device change during a motion grab? I think that there is no device change, in my reproduction steps it happens when the pointer reaches the edge of the tool palette/dockables window (where the cursor to resize the window would be shown) that GIMP receives a motion notify event (probably synthesized) with the default device instead of the currently active. Given it is a motion-notify event and GIMP is painting I thought it is better not to lose it, but it could be better to check because with GIMP_DEBUG=tool-events I seem to recall that also event->{x,y} were relative to the dockable windows. So if you find a better solution go ahead.
This indeed explains quite a lot of bugs, I just wonder why I could never reproduce it, maybe it simply doesn't happen with my wacom tablet/driver combination. I'm wondering if we shouldn't simply check for any mouse button being pressed for that code to be skipped, instead of that specific event, maybe that would be an even safer approach? Massimo, Jehan: does the even state contain GDK_BUTTON1,2,3_MASK?
(In reply to Michael Natterer from comment #6) > This indeed explains quite a lot of bugs, I just wonder why I could > never reproduce it, maybe it simply doesn't happen with my wacom > tablet/driver combination. > > I'm wondering if we shouldn't simply check for any mouse button being > pressed for that code to be skipped, instead of that specific event, > maybe that would be an even safer approach? > > Massimo, Jehan: does the even state contain GDK_BUTTON1,2,3_MASK? event->motion.state is 00000110 and the coordinates are correct, the ones I'v seen with negative numbers are when I set the airbrush tool for the pen (different tool than mouse).
Is that a decimal 00000110?
(In reply to Michael Natterer from comment #8) > Is that a decimal 00000110? Sorry, hexadecimal "%08x".
I tested a little more this issue. There are two cases: when the tool used by the pen is the same as the mouse and when it's not. When they're the same, the tool switch fails and there are warnings on the console, but the stroke is undoable and the selection does not remain paused. When they're different, there are no warnings, the stroke is stopped, it is not undoable and the selection is paused. Both these problems are fixed by the patch attached above. There is another minor issue. When you change the tool the device changed is the last seen on the canvas. If you're using the rectangle selection tool with the mouse and leave the pointer on the tool box, now clicking on a tool button with the pen still changes the mouse tool. You have to move the pointer on the canvas and then on the tool box to change the pen tool. This is not fixed.
Ok what a pile of shit. I'll plug my tablet again this weekend and try to test that myself...
(In reply to Massimo from comment #10) > > > There is another minor issue. When you change the tool the device > changed is the last seen on the canvas. If you're using the rectangle > selection tool with the mouse and leave the pointer on the tool box, > now clicking on a tool button with the pen still changes the mouse tool. > You have to move the pointer on the canvas and then on the tool box to > change the pen tool. This is not fixed. So the problem seems to be here: https://git.gnome.org/browse/gimp/tree/app/widgets/gimptoolbox.c#n271 not all my devices have a cursor and so the subsequent calls to gtk_widget_add_events and gimp_devices_add_widget are skipped and the toolbox probably does not work as intended. The first device missing the cursor has name: Virtual core XTEST pointer besides I did not enable all tablet inputs (not sure if relevant)
(In reply to Massimo from comment #10) > There is another minor issue. When you change the tool the device > changed is the last seen on the canvas. If you're using the rectangle > selection tool with the mouse and leave the pointer on the tool box, > now clicking on a tool button with the pen still changes the mouse tool. > You have to move the pointer on the canvas and then on the tool box to > change the pen tool. This is not fixed. Is the following related to the above issue? It took me a long time to figure out what was causing my image zoom to suddenly change, but here's the sequence of events: In MWM, select the brush. Then click on the tool options dialog, inside the numbers that set the brush size, to try to type in a new brush size. If the cursor is inadvertently moved away from the tool options dialog, unexpected things happen. If the cursor is over the canvas, the canvas zoom changes. If the cursor is over the FG/BG Color dialog or over in the empty space (the desktop) between the image and the toolbox, the FG color changes. This is the case before and after applying Massimo's patch. In SWM, clicking on the brush tool size slider, inside the numbers that set the brush size, makes it possible to then type in a new brush size regardless of where the cursor might be moved to in the meantime.
Created attachment 335795 [details] [review] don't switch tool while painting The attached patch adds a device change check when a tool button is clicked that apparently fixes the other issue I've noticed. motion notify events received on the toolbox are hints (apparently always originated by Core pointer) if tooltips are enabled and they do not propagate til the toolbox when tooltips are disabled.
(In reply to Elle Stone from comment #13) > (In reply to Massimo from comment #10) > > There is another minor issue. When you change the tool the device > > changed is the last seen on the canvas. If you're using the rectangle > > selection tool with the mouse and leave the pointer on the tool box, > > now clicking on a tool button with the pen still changes the mouse tool. > > You have to move the pointer on the canvas and then on the tool box to > > change the pen tool. This is not fixed. > > Is the following related to the above issue? It took me a long time to > figure out what was causing my image zoom to suddenly change, but here's the > sequence of events: > > In MWM, select the brush. Then click on the tool options dialog, inside the > numbers that set the brush size, to try to type in a new brush size. If the > cursor is inadvertently moved away from the tool options dialog, unexpected > things happen. If the cursor is over the canvas, the canvas zoom changes. If > the cursor is over the FG/BG Color dialog or over in the empty space (the > desktop) between the image and the toolbox, the FG color changes. This is > the case before and after applying Massimo's patch. > > In SWM, clicking on the brush tool size slider, inside the numbers that set > the brush size, makes it possible to then type in a new brush size > regardless of where the cursor might be moved to in the meantime. Guessing I'd say it is not related, but the key is how the cursor is inadvertently moved? Does this motion also generate press/release/click/drag events? There are so many variables involved.
A small note which should not be a blocker on how we fix now but a reminder for the future: with Wayland, each device will apparently have its own independent pointer. Has anyone ever tested how GIMP performs with GTK+3 + Wayland? I feel like our device-handling code will go to hell there.
Our device handling code in gtk3-port is already half ported, all functions we use in master are deprecated.
The same problem happens in 2.8, btw.
Changing the summary to reflect our findings.
It turns out that if/when the device change is triggered when using the stylus depends on what other items besides the image itself are shown in the image window. By default, when starting GIMP in MWM the image window is shown with ruler, scrollbars, menu bar, and status bar all visible. It seems when the image itself is completely surrounded by these other items, when using the stylus the brush can be moved completely outside the image window in any direction without triggering a device change or terminal warnings. If the scrollbars are then removed, moving the brush past the right edge causes a device change. If the status bar is also removed, moving the brush past the right or bottom edge causes a device change. Also at this point (at least on my Gentoo Linux install) moving the brush vertically causes artifacts to show in the vertical ruler (but no artifacts show in the horizontal ruler regardless of the direction the brush is moved). If the rulers are also removed (but the menu bar remains), moving the brush past any edge except the top edge triggers the device change. If the menu bar is also removed, moving the brush past any edge triggers the device change.
So it isn't necessary to move into a dock for this to happen? We might have to split this into a new report, because we focused on switches happening at dock edges.
(In reply to Michael Schumacher from comment #21) > So it isn't necessary to move into a dock for this to happen? We might have > to split this into a new report, because we focused on switches happening at > dock edges. Hmm, I'm not really sure what you mean by "move into a dock". The issues I'm trying to describe happen by moving the stylus across the borders of the window that contains the image. It's not necessary to move the stylus to cross another window such as the toolbox. It's sufficient to move the stylus to/past the edge of the window containing the image. I think the "corrupt ruler" issue is separate as it also happens in SWM and doesn't happen in GIMP 2.8. The "trigger" for the vertical ruler suddenly looking very strange is not showing the status bar and moving the mouse or stylus vertically over the image. This might only be a Gentoo issue - I haven't asked someone not using Gentoo to confirm, so my apologies for mentioning it.
Created attachment 335929 [details] [review] don't switch tool while painting As Jehan suggested in comment #4 it is better to ignore the spurious event. It has a wrong device that is used later to retrieve device info/events history/whatever. But the problem is that painting behind the toolbox overlapping the canvas showed an artifact in correspondence of the toolbox edge, probably when the core pointer has a brush size != the current device. The attached patch seems to avoid this kind of artifacts and as the previous fixes all the other problems observed with the exception of the vertical ruler artifacts.
Created attachment 335981 [details] [review] don't switch tool while painting If there are no objections I'm going to push the attached patch tomorrow to master and gimp-2-8. It does not include the device change when pushing a tool palette button because I think it is better dealt with in bug #667862 (perhaps adding a link icon/button to the device list to declare which devices have the same tool settings) I tested it with master and gimp-2-8 on linux and gimp-2-8 on Windows.
That looks nice. Can you add a small comment mentioning this bug please?
(In reply to Elle Stone from comment #22) > I think the "corrupt ruler" issue is separate as it also happens in SWM and > doesn't happen in GIMP 2.8. The "trigger" for the vertical ruler suddenly > looking very strange is not showing the status bar and moving the mouse or > stylus vertically over the image. This might only be a Gentoo issue - I > haven't asked someone not using Gentoo to confirm, so my apologies for > mentioning it. The "corrupt ruler" issue also happens in GIMP installed on Debian testing. Should I file a separate bug report?
I pushed the patch with a comment mentioning this bug report. Not closing for ruler artifacts. (In reply to Elle Stone from comment #26) > (In reply to Elle Stone from comment #22) > > I think the "corrupt ruler" issue is separate as it also happens in SWM and > > doesn't happen in GIMP 2.8. The "trigger" for the vertical ruler suddenly > > looking very strange is not showing the status bar and moving the mouse or > > stylus vertically over the image. This might only be a Gentoo issue - I > > haven't asked someone not using Gentoo to confirm, so my apologies for > > mentioning it. > > The "corrupt ruler" issue also happens in GIMP installed on Debian testing. > Should I file a separate bug report? I know GIMP devs prefer to have a single issue per bug report, I like to see all related issues in the same report. But in this case I'd say it is unrelated, so if you want to file a new report, please resolve this one as fixed.
(In reply to Massimo from comment #27) > I pushed the patch with a comment mentioning this bug report. > Forgot the commit numer: commit 3a44989a4528a16474d41575aa61303f3fe4cc91 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Thu Sep 22 18:18:40 2016 +0200 Bug 771444: Tablet stylus misbehaves when crossing... the edge of a dock in multi-window-mode when the pointer is grabbed do not process a motion-notify-event having the wrong 'device' member. This avoids a harmful device change. (cherry picked from commit 5037ff35ca6bc21fa2b8dcddec7f5df50c2b2c29)
(In reply to Massimo from comment #27) > I pushed the patch with a comment mentioning this bug report. > > Not closing for ruler artifacts. > > (In reply to Elle Stone from comment #26) > > (In reply to Elle Stone from comment #22) > > > I think the "corrupt ruler" issue is separate as it also happens in SWM and > > > doesn't happen in GIMP 2.8. The "trigger" for the vertical ruler suddenly > > > looking very strange is not showing the status bar and moving the mouse or > > > stylus vertically over the image. This might only be a Gentoo issue - I > > > haven't asked someone not using Gentoo to confirm, so my apologies for > > > mentioning it. > > > > The "corrupt ruler" issue also happens in GIMP installed on Debian testing. > > Should I file a separate bug report? > > I know GIMP devs prefer to have a single issue per bug > report, I like to see all related issues in the same report. > > But in this case I'd say it is unrelated, so if you want to > file a new report, please resolve this one as fixed. OK, here's the bug report for the ruler: https://bugzilla.gnome.org/show_bug.cgi?id=771851
(In reply to Massimo from comment #15) > (In reply to Elle Stone from comment #13) > > (In reply to Massimo from comment #10) > > > There is another minor issue. When you change the tool the device > > > changed is the last seen on the canvas. If you're using the rectangle > > > selection tool with the mouse and leave the pointer on the tool box, > > > now clicking on a tool button with the pen still changes the mouse tool. > > > You have to move the pointer on the canvas and then on the tool box to > > > change the pen tool. This is not fixed. > > > > Is the following related to the above issue? It took me a long time to > > figure out what was causing my image zoom to suddenly change, but here's the > > sequence of events: > > > > In MWM, select the brush. Then click on the tool options dialog, inside the > > numbers that set the brush size, to try to type in a new brush size. If the > > cursor is inadvertently moved away from the tool options dialog, unexpected > > things happen. If the cursor is over the canvas, the canvas zoom changes. If > > the cursor is over the FG/BG Color dialog or over in the empty space (the > > desktop) between the image and the toolbox, the FG color changes. This is > > the case before and after applying Massimo's patch. > > > > In SWM, clicking on the brush tool size slider, inside the numbers that set > > the brush size, makes it possible to then type in a new brush size > > regardless of where the cursor might be moved to in the meantime. > > Guessing I'd say it is not related, but the key is how the > cursor is inadvertently moved? Does this motion also generate > press/release/click/drag events? > > There are so many variables involved. I think you are right, this is a separate issue. I can trigger the same behavior with other applications (such as trying to place the cursor using the stylus while typing an email). As far as I can tell the issue of painting in MWM past the edge of the image window is solved by the patch that was just uploaded.
FYI: I just rebased gtk3-port and complelete removed this patch. gtk3-port grabs specific devices and remembers them (gtk3 style), and already ignores all events from all other devices.
(In reply to Michael Natterer from comment #31) > FYI: I just rebased gtk3-port and complelete removed this patch. gtk3-port > grabs specific devices and remembers them (gtk3 style), and already ignores > all events from all other devices. Ok, it's the right thing. The only thing left is for gtk3-port to make it possible to configure input devices (see my comment #2) https://git.gnome.org/browse/gimp/tree/app/widgets/gimpdeviceinfoeditor.c?h=gtk3-port#n137 https://git.gnome.org/browse/gimp/tree/app/widgets/gimpdeviceinfoeditor.c?h=gtk3-port#n210 https://git.gnome.org/browse/gimp/tree/app/widgets/gimpdeviceinfoeditor.c?h=gtk3-port#n408 I did not compile gtk3-port yet, but I see 'axis_use_strings' is short or it is still looping too many times
Per comment 27
Created attachment 338264 [details] previous behaviour > commit 3a44989a4528a16474d41575aa61303f3fe4cc91 > Author: Massimo Valentini <mvalentini@src.gnome.org> > Date: Thu Sep 22 18:18:40 2016 +0200 > > Bug 771444: Tablet stylus misbehaves when crossing... > > the edge of a dock in multi-window-mode > > when the pointer is grabbed do not process a > motion-notify-event having the wrong 'device' member. > > This avoids a harmful device change. > > (cherry picked from commit 5037ff35ca6bc21fa2b8dcddec7f5df50c2b2c29) Testing on Windows the patch for bug 772005, I've noticed that this commit modified GIMP's behaviour in a particular circumstance. Painting with a tablet stylus, when the core pointer and the stylus have the same tool, a stroke going outside the window used to be stroked normally, apart from the pressure value being wrong (probably maximum) at the reentry point. Now the exit and reentry points are connected with a straight stroke. OTOH painting behind a dockable is improved. Attaching two screenshots showing the strokes after having moved downward the dockable to reveal the stroke behind it. Feel free to revert, ifdef out on Windows or whatever if you think it was better without this commit. [When the core pointer and the stylus tool are different, the behaviour was like on linux with the stroke stopped at the exit point not undoable and the selection paused]
Created attachment 338265 [details] current behaviour
Can you file new bugs for the two issues you have encountered, i.e. the pressure maxing and the exit/entry point connecting?
(In reply to Michael Schumacher from comment #36) > Can you file new bugs for the two issues you have encountered, i.e. the > pressure maxing and the exit/entry point connecting? https://bugzilla.gnome.org/show_bug.cgi?id=773359 For the pressure there is already bug 767467. I did not reproduce the selection crash though.
*** Bug 732064 has been marked as a duplicate of this bug. ***
Apparently, the changes done did not fix this issue - or a new one has taken its place. See bug 771265, for example.