Re: Standardizing _METACITY_UPDATE_COUNTER

[Havoc Pennington <hp redhat com>]

Hi,

The danger is that by trying to make this 100% reliable rather than 99%
reliable you're likely to make it much more complex and much more buggy.
If I understand correctly, the failure mode you're worried about is
fallback to the current opaque resize situation, _and_ we don't really
expect this to happen, right?

But with a strict 1-to-1 rule the failure mode is potentially that the
window stops resizing or other total confusion, _and_ it's likely to
happen sometimes due to toolkit or WM bugs. Also likely to have to do
complicated anti-race-condition stuff e.g. in the case Owen points out
when the window first opens.

I'm just thinking of the GtkWindow ConfigureNotify handling code, and
the experience of hacking on it, and I just can't imagine wanting to add
anything else that cares about that whole nightmare...

I may remember badly, but I think the definition I had in mind was just:

 - the toolkit notifies whenever the client window just finished a 
   "complete frame"
 - there's a requirement that you have to notify of a complete frame
   anytime you get ConfigureNotify
 - the WM waits for at least one complete frame event between sending 
   configure events

This is just simple, IF it solves the problem. The question in my mind
is, how real/common is the case where we end up not solving the problem
with this simple solution. And is it fundamentally uncommon or
accidentally uncommon due to timings or races.

Also, metacity does have a timeout as well, as Lubos mentioned for KWin.
Would this break the 1-to-1? I think you need the timeout in case of
really slow/sucky/locked-up apps.

Don't take my comments too seriously since I haven't looked at this in a
while.

Havoc