Re: Compositing managers spec
- From: Carsten Haitzler (The Rasterman) <raster rasterman com>
- To: Lubos Lunak <l lunak suse cz>
- Cc: wm-spec-list gnome org
- Subject: Re: Compositing managers spec
- Date: Wed, 6 Feb 2008 08:23:07 +1100
On Tue, 5 Feb 2008 14:23:47 +0100 Lubos Lunak <l lunak suse cz> babbled:
> 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.
we could recycle that - didn't think of that actually.
> --
> 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//www.suse.cz
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster rasterman com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]