[haiku-development] app_server compositing
- From: Joseph Groover <looncraz@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 20 Mar 2012 16:53:45 -0500
Howdy again!
I would like to get some input as to which direction we should go for
app_server compositing. Compositing allows for transparency effects
such as shadows and alpha-blended corners (making rounded window
decorators much prettier).
The only real complexity when implementing a compositing app_server is
resource utilization. You can go with either full or partial compositing...
A fully composited app_server - making EVERY window draw into its own
buffer, with or without a back-buffer, and merging the data together in
the screen-buffer(with or without double-buffering) would be ideal...
and the easiest to code... - if we could get things fast enough -
A partially composited app_server is much more complex.
You implement a new BWindow flag: something akin to B_RENDER_COMPOSITE.
BWindows with that flag will be drawn into their own buffer, and BView
added directly to a BWindow with B_RENDER_COMPOSITE set will have a
default alpha-channel value of zero (the window composite buffer is
zero-filled). That is all very simple. The fun comes in supporting the
hold with the new, that is... composited & non-composited windows on the
same screen at the same time...
Normal windows render into the screen(front) buffer as they do now, but
when their draws cover an area in which a compositing window 'resides'
the relevant areas of the composting windows (if in front) are marked as
'dirty'. The dirty areas will then have the relevant data from the
composited windows' buffer "mixed" with the front-buffer. The
rendering, then, must occur from the bottom-most composited window, to
the top-most. Then of course, there is the case of a composited window
updating in-front of a non-composited window(such as the Desktop), the
updates will cause the lower windows to need to redraw... or for a
side-buffer of those draws to be made (or use a full-size side-buffer
which exclusively stores non-composited draws - we have options...).
Basically.. LOTS of clipping action & complexity. But, it should be
notably faster than full compositing - and more resource-friendly
all-around - but complexity means more room for errors and flaws... and
much more time. It might be best to couple this with double-buffering,
but we would need to make that determination once a working
implementation is in place - double buffering isn't terribly complex to
institute, but it does add a delay from window update to visibility...
The biggest question is should we just try implementing a fully
composited app_server (since it is the easiest to code) and then rely on
performance improvements to pave the way? Or should we just skip to the
partially compositing app_server?
I would like to go with the fully composited app_server. It is the most
feature-filled and the easiest to maintain. A simple flag in the
app_server could switch compositing on/off live, with transparency
effects being disabled (and a notification to each BWindow).
Opinions, input, corrections, ideas, all welcomed and encouraged!
--The loon
Other related posts:
