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


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