Re: XTranslateCoordinates() performance problem

[Keith Packard <keithp keithp com>]

Around 1 o'clock on Nov 16, Owen Taylor wrote:

> "...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..."

The intent of the ICCCM authors was to have window managers always send 
synthetic configure notify events, but it looks like they missed the 
important resize case that we're interested in here.  The paragraph above 
that one:

"If the window manager moves a top-level window without changing its size,
 the client will receive a synthetic ConfigureNotify
 event following the move that describes the new location
 in terms of the root coordinate space."

seems to let window managers off the hook -- it doesn't require the 
synthetic event we need.

I believe most window managers *will* send the synthetic event, but that 
it will always come after the real event.  Xt allows for the event to be 
missing by calling TranslateCoordinates in case the event doesn't arrive.  

Certainly we can't assume the events will arrive; as you say, there are 
plenty of broken window managers around.  But, I believe we should trust 
that most will send the event and code your idle loop fixup as a backup 
just as Xt does -- when the app receives a real config event, it should 
make sure that TranslateCoordinates is eventually called if no synthetic 
event is received.  A very short timeout should suffice to keep things 
working.

> 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:

It doesn't matter -- the application isn't listening for config events on
the parent, so the movement of the window caused by the parent
reconfiguring isn't signalled by an event to the client.  

When the client window does get reconfigured, it has no idea if it has been
recently moved as well.  You really must assume the worst and expect to
need a TranslateCoordinates unless a synthetic configure arrives soon.

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

No, it's a performance hit for broken window managers which probably do 
exist.  Note that there's nothing that can be done about moving the window 
without resizing -- unless the window manager sends a synthetic configure 
notify event, the application will never hear about the movement.

The synthetic events were added quite late in the ICCCM process when we
discovered that applications *couldn't* know when they'd been moved and not
resized. Applications were already using the ConfigureNotify event on
resize as a hint that the position might have changed and so the ICCCM was
amended to include the required synthetic configure notify event so that
even naïve applications would work correctly -- I believe the expectation
was that the synthetic event could be used to trigger the same
TranslateCoordinates call that the real events from resize already caused. 

Hence the requirement only for move and not resize -- resize already 
generated *an* event, even if the contents of that event were broken.  

Recall that resize was *very* expensive in those days and while I hacked 
opaque resize into twm in 1991, it was so slow that I ripped it right back 
out again.  Requiring a round trip on resize was not unreasonable then, 
but it is now.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.