Re: Freezing updates for compositing managers

Hi Owen,

Owen Taylor wrote:
> Fixing this really requires application intervention - when the
> compositor receives the MapNotify for the window the window might
> have drawn yet, or might not, and there's no way that the
> compositor can know.
> 
> This is actually a symptom of a more general situation - an
> application wants to make multiple X requests (here a map and
> then the redraw) and not have the compositor draw until it is done.
> 
> Thinking of it that way - that gives a pretty straightforward
> solution - the app can set a property that says "don't update me" -
> say _NET_WM_FREEZE_UPDATES - and then remove it when it is ready
> to be painted again.

Sounds like an excellent idea, however it also sounds similar to 
something that the wm-spec already have - can we use the existing 
_NET_WM_SYNC_REQUEST protocol for that? Since compositing manager might 
already support it, it could be pretty straightforward to implement the 
same protocol for the case when a client window is initially mapped. For 
example, when the compositor receives the MapNotify, it might send the 
_NET_WM_SYNC_REQUEST client message and delay showing the window until 
the client responds by setting a _NET_WM_SYNC_REQUEST_COUNTER.

-- 
Denis Dzyubenko
Software Engineer
Nokia, Qt Software