Re: Compositing managers spec

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 1 Feb 2008 16:37:33 +0100 Sanel Zukan <sanelz gmail com> babbled:

> Carsten Haitzler wrote:
> > * do not delay my output to try coalesce rendering updates (if the composite
> > manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from
> > xdamage events to try and wait for more updates to occur so it can update to
> > screen in 1 go and not in lots of small updates, making window re-draw look
> 
> Hm... isn't the point of xdamage (and the family) to do a lot of small
> but precise updates?

the point of xdamage is simply to deliver events stating which rectangular
region(s) of a drawable have been drawn to - when they are drawn to. it is up
to the CM as to what to do with them. generally speaking the CM will then
pretty much instantly queue up redraws for he corresponding regions on the real
screen.

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.

> > "smoother" as it happens at once and not bit by bit, but some apps - like
> > video players and games, will definitely not want this as they probably do
> > whole updates in 1 go anyway).
> 
> So, you are proposing removing delay in updates or waiting for a larger number
> of events and update everything in once or maybe signaling cm to do
> update for the whole screen, e.g. when video player goes fullscreen?
> (I didn't understaind this well)

no - see above. it's a hint that says "if you have some smart stuff that may
delay an update more than it could be delayed, to try and reduce updates,
please don't do this as it's pointless for me because i already am smart about
drawing". :)

> > * please provide a solid background even if my window is ARGB because i am
> > allowing the wm border/decoration to define the backing of my window and the
> > contents should be composited over whatever backing the WM provides (the
> > problem with window decorations is that they are separate from window
> > background. it is impossible to reliably have a titlebar seamlessly continue
> > into the app window with textures, patterns, shading etc. without
> > fastidiously fixing up themes/widgets/whatever of every toolkit. if
> > toolkits were to render to ARGB dest windows and simply NOT render a
> > background color/pattern for the window, but leave it transparent with all
> > buttons, other widgets, labels rendered onto a dest-alpha transparent ARGB
> > window, then the window content is a composited overlay on top of a window
> > frame "Decoration" that also defines the decorations UNDER the window
> > contents, allowing for smooth transitions from titlebars and borders into
> > the window contents).
> 
> But, this sound for me more like a toolkit issue. I'm not sure how
> gtk/qt/others will adopt this, but I'm sure this will not go easily in FLTK
> (except if I create my own branch).

it is a toolkit issue. *IF* the toolkit renders ARGB and is expecting the CM/WM
to provide a backing image that is part of the frame/border, then the CM/WM
knows to provide this as opposed to thinking the ARGB window is intended to be
transparent over other windows.

this allows for the background to be seamless with the window frame and match
properly. nothing does this (yet), but it'd be very useful if available and
later used by toolkits. adopting is easy if ARGB visual window, draw background
with alpha of 0x0, instead of 0xff+color. the rest is the same :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com