[haiku-development] Re: app_server compositing
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 21 Mar 2012 20:00:16 +0100
Am 20.03.2012 22:53, schrieb Joseph Groover:
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).
Are you aware of the following article?
https://www.haiku-os.org/articles/2011-06-15_how_transform_app_server_code_use_compositing
The only real complexity when implementing a compositing app_server is
resource utilization.
Hm, what do you find challenging about it? I would think the challenging
part is how exactly to define the screen update flow to achieve a
constant 60 fps screen update refresh (when needed) while individual
windows may take longer to provide a new clean buffer. And how to make
sure to never show dirty buffers on the screen within this flow of
updates. The next challenge is how to design it in such a way that the
majority of the code and design will still work when a first driver is
available with hardware acceleration that can be used for the
compositing. Keeping in mind that the hardware may also be used by other
stuff, like OpenGL. I think the buffer management is one of the simpler
things to implement.
You can go with either full or partial compositing...
True. The benefit of partial compositing would be less resource
consumption since clipping based windows don't need a buffer. There are
however significant draw-backs with the partial compositing. You can't
provide window previews elsewhere and you have a *lot* more CPU overhead
since you need to re-render everything bottom up when trying to place a
buffered window within the stack.
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 -
You are concerned about being able to make compositing fast. It may
indeed be a challenge, but you are forgetting about the CPU cost of
always having to paint windows in the clipping based approach, which
takes a lot of CPU compared to caching these results in the buffers.
A partially composited app_server is much more complex.
Indeed.
[...]
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?
What makes you believe that the partitial compositing would be faster
than full compositing? Think about it, if you need to render all
clipping-based windows from bottom to top, inserting buffered windows as
you go, you need to generate every pixel of every clipping-based window
in the update region. Asking the clients to do it, no less! Do you think
that will be faster than simply alpha blending a cached window buffer?
IMHO, the *only* draw back of buffered windows is their memory
consumption. They are better/faster in every other way.
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).
Yes, making the back-end switchable is definitely the way to go. Any
Linux distribution and even Windows has to make compositing optional in
order to be able to run on lesser or unsupported hardware (the latter
not a concern for a CPU-based implementation, of course).
Otherwise my article may contain some useful implementation details...
It's great you want to work on this! (But I have said that a few times
before... :-D)
Best regards and good luck!
-Stephan
Other related posts:
