I have been trying to fix a bug affecting the paint tools on systems
with two monitors (possibly only Xinerama systems), and have run into a
few snags that I would appreciate some help with. (I'm pretty sure that
this bug has been reported in Bugzilla, but the closest report I can
find is 168880, and that is incomplete; I will open a new bug if I can't
find an existing report.)
I use Xinerama to extend my desktop. My setup looks like this:
+------------------+-----------------------+
| | | |
| 1024x768 | | |
| | 1280x1024 | |
| | | |
+------------------+ | |
| | |
+-----------------------+
The monitor to the left is ordinarily filled with panels (the toolbox,
layers, channels, brushes, etc), while the higher-resolution monitor is
used to hold the image I'm editing. The problem is that when I use a
paint tool (on the higher-resolution monitor), I cannot paint past the
1024th horizontal display pixel (indicated by the line in the figure
above). Painting past the 768th vertical display pixel works fine. What
happens when I try to paint past the 1024th horizontal display pixel is
that pixel x - 1024 is painted instead. (To be precise, just pressing
the primary mouse button once works, and moving it one pixel in any
direction also works; I get the behavior described above when continuing
to paint past the 1024th horizontal display pixel.)
I have been trying to investigate this bug using GDB, and while I have
come up with a solution that cures the problem, it's likely not the
correct fix. This seems to be a GDK problem, but I would like some
feedback from this list on whether this is indeed the case.
gimp_display_shell_canvas_tool_events() (in
gimpdisplayshell-callbacks.c) seems to be called whenever an event is
fired, such as the user moving the mouse pointer, or pressing a button.
When the user is moving the mouse, the event is GDK_MOTION_NOTIFY (line
1086 in 2.3.18). The code that calls the mouse motion code of the active
tool (tool_manager_motion_active()) is called in one of two places in
the GDK_MOTION_NOTIFY code, depending on whether GDK believes that there
are any "motion history events" associated with the current device
(through gdk_device_get_history()[1]); the code roughly looks like this:
[1]
http://library.gnome.org/devel/gdk/unstable/gdk-Input-Devices.html#id2970254
if (there are motion history events)
{
iterate over the motion history events and transform the coordinates
call the motion code of the active tool with the new coordinates
}
else
{
call the motion code of the active tool with the old coordinates
}
(This explains why I can paint once, and move the mouse pointer one
pixel before I get the erroneous behavior.)
I have noted that if I paint in the left part of the image (0 < x <
1024), GDK never reports that there are any motion history events, and
thus, the motion code of the active tool is called with the old
coordinates -- at all times, and things work as expected. If, however, I
paint past the 1024th horizontal display pixel, GDK _will_ report that
there are motion history events, and thus, GIMP will attempt to iterate
over the history events and (incorrectly) modifies the coordinates,
leading to the behavior described above.
The upshot is that if I simply comment out the first block, and always
go with the old coordinates, everything works like a charm:
/*if (there are motion history events)
{
iterate over the motion history events and transform the coordinates
call the motion code of the active tool with the new coordinates
}
else*/
{
call the motion code of the active tool with the old coordinates
}
I'm sure that GDK is queried for the motion history for a reason, though
(although it doesn't seem to ever work on my system). I'm happy that I
have managed to fix a bug -- at least for my own purposes -- that has
annoyed me for some time now, but it doesn't seem to be a proper fix.
I'd be happy to send a patch that can be applied to the Subversion
trunk, but as noted, I would like to get some feedback on this first.
I'm using Ubuntu Feisty Fawn.
Regards,
--
David Polberger
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
