Re: Compositing managers spec

On Saturday 02 of February 2008, Carsten Haitzler wrote:
> a lot of apps will update their window by drawing all the parts that
> change. if they do not double-buffer theme selves they will draw directly
> to the front-buffer. this means that to draw a button that goes from light
> red to deep pink and looks pressed-in, it may very easily draw a new base
> color, then draw the lines surrounding the box to make it look indented,
> then redraw the label in the middle. in theory this can easily be half a
> dozen or more damage events for the same region. if the CM simply draws on
> every damage event - u'll get lots of extra compositing going on. if its
> smart it will queue updates and wait until all damage events have been read
> then update. if it gets really smart it may even delay a bit then as more
> damage events may be on their way but not in the buffers yet. it may also
> wait until vsync
> sometimes such extra delays that are artificially added beyond draining all
> damage events could lead to bad sync. situations - eg - video players. they
> will update the whole video at once anyway. so for apps hat are "smart"
> about drawing and double-buffer themselves, and care about getting updates
> up ASAP - set a property. for "legacy" or "stupid' apps - the CM can play
> some heuristics games by adding small delays to gathering all damage events
> to make sure it queues up as many as it can for 1 on-screen update to
> improve smoothness of screen updates as much as possible.

 There is _NET_WM_SYNC_REQUEST, which is a way to detect when the client has 
finished doing a repaint. It is unfortunately bound to ConfigureNotify 
events, but I think that's not a real problem in practice.

Lubos Lunak
KDE developer
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//

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