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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to