Re: Standardizing _METACITY_UPDATE_COUNTER

[Soeren Sandmann <sandmann daimi au dk>]

I guess my first mail wasn't too clear. This one is hopefully more to
the point:

Havoc's patch and the Qt patch

         - Havoc's GTK+ patch is different from the Qt patch. Havoc's
           patch makes gtk+ bump the counter every time anything
           changed for any reason. The Qt patch (as I understand
           Raynier's explanation) bumps the counter whenever it has
           seen a number of ConfigureNotifies and finished handling
           them.

         - Havoc's patch does not work. If the application window
           contains an animation, then the patch will send a stream of
           counter bumps that will cause the window manager to keep
           resizing even though the application possibly haven't even
           *seen* the previous ConfigureNotifies.

         - I don't see any reason the Qt approach wouldn't work (but
           see below for why I think it can be improved).

One-to-one approach

         - Every time the toolkit sees a configure notify (before
           compression or anything else) it increments a (plain old
           C/C++) variable called "unacknowledged_configure_notifies"
           (u_c_n).

         - When the toolkit has finished layouting and drawing, it
           increments the X SYNC counter by the value of u_c_n and
           resets u_c_n to 0.

         - The window manager generally sends a ConfigureNotify and
           waits for the toolkit to acknowledge it.

         - If the toolkit doesn't acknowledge within n ms, the window
           manager should go ahead and send another ConfigureNotify,
           ie. the window manager does have a timeout. I did *not*
           suggest getting rid of the timeout.

So the one-to-one approach is totally simple. No complicated
anti-race-condition stuff. And there _is_ a timeout. In fact, the only
difference from the Qt patch is that instead of always bumping the
SYNC counter by 1, it bumps by the number of ConfigureNotifies it has
seen.

If the window manager in the common (non-timeout) case only sends a new
ConfigureNotify when it has seen the acknowledgment of the preivous
one, then the application will only ever see one ConfigureNotify in
its queue and will never bump by anything else than 1, ie. exactly as
the Qt case.

What's the point then?

- The description of the application-side algorithm is simpler and
  more general:

      "Increment the counter when the application has done the
       processing associated with the ConfigureNotify, ie. the counter
       represents the number of handled ConfigureNotifies. "

  That doesn't involve the notion of "full frame", which may not make
  any sense for some toolkits. The concept "processing associated with
  ConfigureNotify (whether delayed or not)" _does_ make sense for all
  toolkits.

- The window manager can keep track of where in the ConfigureNotify
  stream the application is.

  This means a window manager can have the policy that an application
  can be up to "k" ConfigureNotifies behind. A sophisticated window
  manager could even measure the time an application usually takes to
  handle a configure, factor in the round trip time, and base its
  value of "k" on that. Yes, that's complex, but window manager don't
  have to do it if they don't want. But with the one-to-one approach
  they have the possibility.

  Note that if the window manager has the (reasonable) policy of 
  "k == 1", the whole thing is exactly equivalent to the Qt approach.

I don't think these two points are total killer advantages, but I do
think they make it worthwhile making the very simple change from

        "say when you have handled _some_ ConfigureNotifiy" 

to 

        "say _how many_ ConfigureNotifies you have handled".

Because the last one isn't at all difficult to implement and it
significantly increases the amount of information the window manager
gets.

Owen's points:

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

        - Do we acknowledge synthetic ConfigureNotifies? Yes, as Lubos
          points out, it is hopeless to try to figure out which ones
          to ignore.


Søren