Re: Standardizing _METACITY_UPDATE_COUNTER



On Sun, 2004-02-22 at 10:42, Soeren Sandmann wrote:

>         - When a window manager first manages a window, the
>           application could have queued up a number of
>           ConfigureNotifies. To the window manager this will look like
>           spurious counter updates, something which it must be robust
>           against under all circumstances. 
> 
>           This doesn't break anything; a window manager should just
>           know that the counter updates come from an unreliable
>           source. That will be the case under all the schemes. 

I don't quite understand how the window manager is robust here; of
course, it can't crash under any circumstance, but since it can't tell
that these  left over counter increments are from previous
ConfigureNotifies, it has no way of ignoring them, it just has to
assume that they are in acknowledgements of its resizes.

Yes, this is a corner case, since normally things will catch up
and when there are no outstanding resizes the counter increments
can easily be ignored.

But I don't think it's that uncommon that:

 - Window is resized before it is mapped so has a queued ConfigureNotify
 - User starts resizing the window as soon as it is mapped
 - App is slow on painting newly mapped windows and on resizing so
   never catches up with the window manager.

So that's why I'm suggesting the serial approach since it eliminates
this problem. A valid point? Obsession with detail? I'll let other
people decide.

To resummarize my proposal:
 
 The window manager sends a client message

  ACKNOWLEDGE_CONFIGURE
   data.l[0], data.l[1]       64 bit counter

  which means "Once you are done processing the next ConfigureNotify
  and associated exposes, acknowledge that you are done by echoing
  the counter value value back to me." (Via client message or
  XSYNC, protocol could be either way.)

 The client is allowed to compress multiple ACKNOWLEDGE_CONFIGURE
 client messages and the associated ConfigureNotify events and just
 use the latest counter value.

Regards,
						Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]