Thanks for working on this. I know it has crossed my mind to tackle it, but I don't have the time and neither the skills to do it (though I guess I could learn.) I know Stephan has probably wanted to work on this too and also lacks the time. I think we open up so many nice (and modern) features by having a compositing app_server, so this is very exciting!
It is my pleasure: I enjoy challenging projects! That and I want the benefits of compositing as well.
I'm making good progress (or at least I think so ;-)): https://github.com/looncraz/haikuI'm systematically working out the kinks of the overall design into a working implementation - and working to keep code changes separate or using code changes to help out the standard mode as well.
I've 'inadvertently' optimized a few code-paths along the way, and I may have solved a clipping bug, so things should be somewhat better with or without compositing enabled (though at this point, we are talking about maybe .5fps in the CompositePerfTest3...).
I'll be making a very detailed write-up about its design as I'm using quite a few little optimizations and tricks that are quite important in other areas of development.
For instance, Decorators will sometimes draw in its window's buffer, and sometimes draw directly to the screen's back-buffer. The same goes with back-ground windows. The Desktop (Tracker) window will paint directly to the back-buffer rather than having its own, a flag will be available to prevent a window from being composited (such as Media Player or VLC) and a method to set a window as the exclusive painter to the screen (games, full-screen video). Also the ability to frame-rate-limit certain windows - such as preventing the Desktop from updating up the window layers any more often than every 1/3 second or so when the performance just isn't there...
Speaking of all that... I'm thinking of merging window stacks into a common buffer...
--The loon
