Package: gimp
Version: 1.1.21

Name........: Garry R. Osgood
Email.......: gosgood@idt.net
Platform....: SGI Indigo IP20, SGI O2 IP32-5K
GIMP Version: 1.1.21
GTK Version.: 1.2.7

-- Other system notes


-- Problem description

Marching ants appear to be dying an untimely death. After about an
hour or two of use, up to now using multiple layers and most selection tools.
Visibility toggle has not been manipulated and remains set to view
marching ants on selections.

--How to repeat

Haven't isolated the trigger; Some time after extensive work I notice
they don't appear. Next chance I get I'll drop Gimp into a debugger
and see what he says.

-- Other comments

This feels like a potentially annoying one to track down.


Be good, be well

Garry Osgood




------- Additional Comments From gosgood@idt.net 2000-10-05 20:48:40 ----

Subject: Partial Isolation
From: "Garry R. Osgood" <gosgood@idt.net>
To: 10498@bugs.gnome.org
Message-Id: <39DD2168.7A9D9D46@idt.net>
Date: Thu, 05 Oct 2000 20:48:40 -0400

Problem Still persists with Gimp 1.1.27.

It occurs reliably when I (1) use a pressure sensitive tablet, and (2)
select the tablet as a device through <Image>->Dialog->Device input.

Never see it otherwise.

Tablets generate extremely large and densely packed plots; methinks this
taxes the display list that gets built for the ants to march around.

The hunt continues...

Garry Osgood




------- Additional Comments From gosgood@idt.net 2000-11-19 05:43:07 ----

Subject: Full Isolation
From: "Garry R. Osgood" <gosgood@idt.net>
To: 10498@bugs.gnome.org
Message-Id: <3A17AEBA.36B4764A@idt.net>
Date: Sun, 19 Nov 2000 05:43:07 -0500

All,

With help from Simon Budig and Raphael Quinet, 
the problem with marching ants has been isolated
to a larger problem involving a change in behavior
in gdk_pointer_grab() when the event stream originates
from XInput devices. Users of this function do not
care what drives the pointer at the application level;
they offer a list of only the events they choose to process during
the pointer grab. For XInput devices only, this function
over-rides the user's list to insure that symmetric events
(button presses and releases) are received. This policy
breaks Gimp code. (see mail list correspondence below).

It is not clear what the benefit of this policy is; GDK
should be a conduit of events, not an editor; it is the
application's providence to decide what events it wants,
and its the application's responsibility to deal with
the effects of choosing to ignore GDK_XXX_PRESS while
receiving GDK_XXX_RELEASE. In fact, areas of Gimp select-edit
code very much depend on button presses being held from
the application during grab operations. In this light,
I will be filing a GTK bug report, and the resolution
of this bug will be dependent on the resolution of that.

I'll post the relevant GTK Bug Report # here when it is
available. I intend to propose a patch to GTK first.

Be good, be well

Garry

[From gimp-developer mail list ---------------------------]

Simon, Raphael, All...

I had the opportunity to spend three or four hours
yesterday afternoon/evening (GMT -5.00) seeking ways
to rescue Marching Ants (#10498).

I can confidently report that a call such as:

return_val = gdk_pointer_grab (gdisp->canvas->window, FALSE,
             GDK_POINTER_MOTION_HINT_MASK |
             GDK_BUTTON1_MOTION_MASK |
             GDK_BUTTON_RELEASE_MASK,
             NULL, NULL, bevent->time);

does not behave identically for core events (Defined in the
original X11 protocol) and XInput Extension events. This is
true when GTK+-1.2.8 has been built with the --xinput=xfree
option. While the GDK event request list is honored for core
X11 protocol events, the XInput events are subject to
special handling. The culprit,
gdk_input_common_find_events(), while nominally in charge of
just mapping the the GDK event request list into appropriate
XInput device classes [gtk+-1.2.8/gdk/gdkinputcommon.h], it
in fact asserts an internal policy of linking symmetric
events.  That is, this code virtually adds
GDK_BUTTON_PRESS_MASK when a client requests only
GDK_BUTTON_RELEASE_MASK -- and vice-versa.

The comment is unhelpful:

  /* We have to track press and release events in pairs to keep
     track of button state correctly and implement grabbing for
     the gxi support */
  if (mask & GDK_BUTTON_PRESS_MASK || mask & GDK_BUTTON_RELEASE_MASK)
    {
      DeviceButtonPress (gdkdev->xdevice, gdkdev->buttonpress_type,
        class);
      if (class != 0)
   classes[i++] = class;
...

[gdk_input_common_find_event() gdkinputcommon.h Line 322 ff]

It is not clear to me why "button state" matters to GDK or
why GTK+-1.2.8/GDK requires events to be linked in this
fashion -- for XInput Extension devices only.

To the contrary, Gimp' family of selection tools require the
alternate circumstance: that during the grab, button press
events cannot be permitted to arrive, else the grand Gimp
event dispatcher, gdisplay_canvas_events()
[disp_callbacks.c], would divert Gimp process flow into a
(likely) menu dispatch. Since many menu implementations are
"tool-like", this can lead to the unloading of the current
selection tool before it has had opportunity to put its
persistent state in order -- thaw the undo stack, for
example. This is especially true for the "Trojan Horse"
tool, edit-select, which, through invitation by some other
select tool (invoking init_edit_selection()), temporarily
substitutes its predecessor's tool methods for its
own. Should this tool become unloaded because of a
menu-related button press, the predecessor's finalize
methods are not called and the tool itself does not have
full opportunity to clean up.

What to do?

Certainly, bug reports to GTK are in order: GTK "promises"
to abstract the pointer so that the application writer does
not have to do anything special with core and extension type
events. Grab semantics should be uniform. Now that I am
confident of the chain of causuality, I can handle that.

In light of an (is it coming? Really?) 1.2 Release
The question I have for the group is:

1) Document, warn, but otherwise ignore the problem.
   It affects users with a certain type of tablet hardware
   and only when that hardware is being used as an explicit
   XInput device. Wait for a GDK fix to remove its hidden policy?

2) Make a Gimp level hack in the much-abused event loop to
   filter button presses that originate from devices when
   a grab is in effect. (not pretty -- except for possibly
   being pretty lame)?

3) Re-engineer select tool code to be more robust in button
   press events (much work here)?

Which of these is the best line of action? Do you have other
proposals?

If no one objects, I would like to elevate #10498 from 'critical'
to 'grave.' Through a chain of causuality originating with edit-select
not being able to perform a thaw, eventually (sometimes) there is
a fatal crash in undo. Not sure why, but grave bugs are the ones
that crash Gimp - at least sometimes.

Thank you to Simon and Raphael for thoughts, observations, snippets
of test code. As an aside, I think Simon is correct in observing
that this bug is also related to Bug #6901, "Can not continually move a
floating selection with a pressure sensitive pointer."?

Be good, be well

Garry




------- Additional Comments From gosgood@idt.net 2000-11-19 16:50:13 ----

Subject: Dependency on GTK Bug #32617
From: "Garry R. Osgood" <gosgood@idt.net>
To: 10498@bugs.gnome.org
Message-Id: <3A184B15.F3D5C418@idt.net>
Date: Sun, 19 Nov 2000 16:50:13 -0500

This is the bug report descibing
the GDK issue, described below.
#10498 depends on it closing.

A trial patch was tested by me 
and posted to gimp-developer.

If that (or an equally effective)
patch is incorporated into GDK 1.2.x,
then this bug can close.

See 
http://bugs.gnome.org/db/32/32617.html

GRO




------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:52 -------
This bug was previously known as bug 10498 at http://bugs.gnome.org/
http://bugs.gnome.org/show_bug.cgi?id=10498
Originally filed under the gimp product and general component.

The original reporter (gosgood@idt.net) of this bug does not have an account here.
Reassigning to the exporter, debbugs-export@bugzilla.gnome.org.
Reassigning to the default owner of the component, egger@suse.de.