[Xorg] Composite and Background == None windows
keithp at keithp.com
Sun Jul 11 09:38:21 PDT 2004
Around 13 o'clock on Jul 11, Soeren Sandmann wrote:
> I doubt any applications actually do this, but they could. The
> protocol spec is unambiguous that depending on this is allowed for
> windows with matching visuals.
Right, but the case I'm most concerned with is the top-level case where
applications can't rely upon the visuals of underlying windows.
Within an application, presumably it would know whether compositing was
enabled for any of its subwindows (implicit compositing happens only
across different visual types).
> To be compatible with the current protocol the screen area needs to be
> copied in the case of reszing a window too. Why not simply copy the
> contents and not generate a DamageNotify? Logically the window is not
> damaged as the application has not painted anything.
That certainly seems like the most reasonable plan. The trouble is with
the 'not generate a DamageNotify' event. Right now, an application will
create and map a window *before* the compositing manager gets notified
that the new window exists. Therefore, the Damage object doesn't get
allocated until after the window is already mapped on the screen.
Currently, Damage objects are automatically filled with the window border
clip when created -- this avoids lots of race conditions in normal usage,
and if the window had actually painted anything (even with a background
other than 'None'), it would be necessary. I don't know how to avoid
damage in the right cases -- it seems like the server would have to track
the affected area *in advance* of any damage object being created.
Perhaps we need some implicit damage creation mechanism, just as we have
an implicit composite creation system.
> I agree with this, although synchronous override redirects as
> suggested in the 'Why X is Not Our Ideal Window System' paper would
> also be helpful in making mapping managed windows flicker less.
Compositing *can* eliminate all flicker if we come up with conventions for
applications and window managers to update at the 'right' times. Perhaps
we need to develop some preliminary mechansism and see whether additions
or changes to the composite or damage extensions are needed to make
that reasonably efficient.
Thanks much for your comments and suggestions!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
More information about the xorg