Re: XTranslateCoordinates() performance problem

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

> Around 23 o'clock on Nov 15, Owen Taylor wrote:
> 
> >  2) Use the last x, y received for the event, then queue
> >     an idle with a priority lower than events in which
> >     you actually call XTranslateCoordinates() and 
> >     synthesize a pure-move ConfigureNotify if the 
> >     x, y you retrieve are different than the last x,y.
> 
> You needn't ever call XTranslateCoordinates -- the window manager will 
> eventually send you a synthetic configure notify whenever your position 
> changes.  Ignore all position information in real configure notify events 
> and replace them with the last coordinates from a synthetic configure.  
> That's what Xt does.  The only effect is that the application is slightly 
> behind the server when resizing occurs, but this is benign as the synthetic 
> event will follow shortly.

Hmmm, section 4.2.3 of the ICCCM says:

"...Any real ConfigureNotify event on a top-level window implies
 that the window's position on the root may have changed, even 
 though the event reports that the window's position in its window
 is unchanged because the window may have been reparented..."

I think as long as a window manager knows a real ConfigureNotify has
been sent, it isn't required to send a synthetic one, even if the
coordinates of the real ConfigureNotify are not useful.

The code xc/lib/Xt/Shell.c:EventHandler() seems to correspond to
this .. it does:

  if (event->xany.send_event /* ICCCM compliant synthetic ev */
      /* || w->shell.override_redirect */
      || w->shell.client_specified & _XtShellNotReparented)
    {
       w->core.x = event->xconfigure.x;
       w->core.y = event->xconfigure.y;
       w->shell.client_specified |= _XtShellPositionValid;
    }
  else w->shell.client_specified &= ~_XtShellPositionValid;

Perhaps all window managers actually _do_ send synthetic events
every time the client's origin moves, even if it isn't
required. I haven't done a survey of window managers in this 
regard. But I've had trouble finding things that all window
managers do, even if they _are_ required by the ICCCM.

Regards,
                                        Owen

Note: it isn't all that likely this case comes up ... usually window
managers don't move and resize applications at once.  The cases where
a simultaneous move/resize might happen to a client are resizing from
the top or left, when:

 - The window manager does not reparent the window, perhaps because it
   is undecorated. This unparented condition should be detectable 
   separately.

 - The window manager is being clever, and set the window gravity on
   the app window to StaticGravity when moving the parent, then moves
   the child separately.

I don't know of any window managers that actually do the second
thought it actually makes some sense ...  it's the only way a client
has the possibility of preventing the jittering of right justified
elements during a opaque resizes from the left.

So, by calling XTranslateCoordinates() instead of using the last
coordinates GTK+ is taking a performance hit for correctness with
hypothetically existant exotic window managers...