GNOME Bugzilla – Bug 677375
tools do not strictly follow mouse pointer (missing motion events)
Last modified: 2012-06-18 16:19:19 UTC
To reproduce: 1) Create new image 2) Select rectangle selection tool 3) Begin to make a selection 4) Move a mouse pointer fast; then stop Sometimes the selection stops at a different (from mouse pointer) position This is not a duplicate of bug #645345, since this can be reproduced without "color management" display filter (though it is more easy to reproduce the with "color management" display filter). I have tested this with latest git from branch gimp-2-8 with latest patch from Massimo fixing the bug #645345. Please, take a look at the screencast: http://www.youtube.com/watch?v=gPATySQRE7c
This problem is not limited to rectangle selection, it affects regular painting as well, though it is harder to reproduce. It's easier to stop in the middle of a fast movement if you just lift the mouse off the pad while moving fast rather than trying to stop.
Reading the documentation I'd say that either GDK_POINTER_MOTION_HINT_MASK should be removed in app/display/gimpcanvas.h or gdk_event_request_motions (mevent) should be added in app/display/gimpdisplayshell-tool-events.c in function gimp_display_shell_canvas_tool_events before returning after processing GDK_MOTION_NOTIFY. What is confusing is: http://git.gnome.org/browse/gimp/commit/?id=8569c6e2f7ebe2204bc01b682397f2cd125393d9 and its comment
Argh, I missed the define in that header. Please go ahead removing it.
Removed. Please test if it fixes the issues. commit d5b6608ad4012a45c9dcb4636dd32f64a0d06d10 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Sun Jun 10 17:20:43 2012 +0200 Bug 677375: tools do not strictly follow mouse... pointer (missing motion events)
I still can reproduce the bug with latest gimp-2-8 (updated up to commit http://git.gnome.org/browse/gimp/commit/?h=gimp-2-8&id=a4ecfde635f993a6c196cacbf357623a93bb0e5b )
instrumenting libgimpwidgets/gimphelpui.c like this: diff --git a/libgimpwidgets/gimphelpui.c b/libgimpwidgets/gimphelpui.c index 8e55211..c096406 100644 --- a/libgimpwidgets/gimphelpui.c +++ b/libgimpwidgets/gimphelpui.c @@ -224,7 +224,21 @@ gimp_help_set_help_data (GtkWidget *widget, if (tooltips_enabled) { + const gchar *type_name = g_type_name (G_TYPE_FROM_INSTANCE (widget)); + if (g_strcmp0 (type_name, "GimpCanvas") == 0) + g_printerr ("%s %p %s %x %x %d\n", G_STRLOC, + widget, + g_type_name (G_TYPE_FROM_INSTANCE (widget)), + gtk_widget_get_events(widget), + gtk_widget_get_events (widget) & GDK_POINTER_MOTION_HINT_MASK); gtk_widget_set_tooltip_text (widget, tooltip); + if (g_strcmp0 (type_name, "GimpCanvas") == 0) + g_printerr ("%s %p %s %x %x\n", G_STRLOC, + widget, + g_type_name (G_TYPE_FROM_INSTANCE (widget)), + gtk_widget_get_events(widget), + gtk_widget_get_events (widget) & GDK_POINTER_MOTION_HINT_MASK); + if (GTK_IS_MENU_ITEM (widget)) gimp_help_menu_item_set_tooltip (widget, tooltip, help_id); shows that gtk_widget_set_tooltip_text is setting the MOTION_HINT flag. The only way I've found to clear definitely that flag is to comment out the three calls to gimp_help_set_help_data (shell->canvas, ...); in app/display/gimpdisplayshell.c, this appears to work. Instead adding gdk_event_request_motions does not work. Don't know if it is better to have a tooltip on the canvas or to follow the mouse faithfully.
Created attachment 216246 [details] [review] Quick and dirty hack Useful only to verify if clearing the GDK_POINTER_MOTION_HINT is sufficient to fix all the issues.
I cannot reproduce the bug with the latest patch.
Massimo, doesn't simply not setting the tooltip have same effect?
(In reply to comment #9) > Massimo, doesn't simply not setting the tooltip have same effect? The same GimpCanvas widget is used for the empty image window and to display the image content. When GIMP is started on that widget it is set a tooltip, when an image is loaded the tooltip is removed, but the flag cannot be reset. This also means that apart the window that used to be the empty image window (showing Wilber), all other windows should not have the problem described here. Obviously never setting the tooltip, solves the problem.
Yeah let's kill the tooltip then, perhaps by #if 0'ing it and adding a comment, so it doesn't get added back when somebody notices it's missing :) Dropping files to an application's window doesn't need to be explained these days i think.
> This also means that apart the window that used to be the empty image window (showing Wilber), all other windows should not have the problem described here. Are you sure about this? We set tooltips on the menu button and rulers, and gtk+ uses the same X window for all of these and the canvas iiuc.
The toplevel X window selects all events anyway, and GDK forwards them the the resp. client-side window, and the canvas has its own window. If this doesn't work, then GDK is broken. X windows are an implementation detail.
(In reply to comment #12) > > This also means that apart the window that used to be the empty > image window (showing Wilber), all other windows should not have > the problem described here. > > Are you sure about this? We set tooltips on the menu button and rulers, and > gtk+ uses the same X window for all of these and the canvas iiuc. I'm sure that: after the commit referenced in comment #4 and without the patch attached to comment #7 a) if you open simultaneously 2 (or more) images in multi-window-mode only one of them exhibits the problem. b) rulers and GimpCanvas don't share the same X window. GimpCanvas creates its own in GimpOverlayBox:realize.
Created attachment 216559 [details] [review] proposed patch A patch disabling (#if 0) the three problematic calls. If there is no objection I'll push it later
Fixed in master and gimp-2-8: commit 5835a730a3eef3cee579c50b250bb8ba15b77d7c Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Mon Jun 18 18:14:43 2012 +0200 Bug 677375: tools do not strictly follow mouse... pointer (missing motion events) Disable calls gimp_help_set_help_data for shell->canavs