How to transform the app_server code to use compositing | Haiku Project

Compositing can initially be implemented without doing lots of changes to the drawing code or how updates work. In the Interface Kit we have BWindow and BView. The BWindow has a messaging port to the app_server. Inside app_server, a ServerWindow (one instance per BWindow) receives any drawing commands which BViews send via their owning BWindow. BViews also have a server counterpart, which is called View, unsurprisingly. There is another class called Window. Window is representing the on-screen object in the server (holds clipping, decorator, ...) while ServerWindow is rather managing the communication and owns one Window object. View objects are owned by Window and mirror the client side BView hierarchy, as long as those BViews are attached. Each Window also owns a DrawingEngine, which abstracts the entire drawing interface. The default implementation for all the supported drawing functions is in the Painter class. Painter itself is using AGG for general purpose drawing algorithm implementation, and has a whole bunch of optimized implementations when it can take a shortcut. So each Window instance owns a DrawingEngine and Painter instance.

This is a companion discussion topic for the original entry at

Hi Stippi. Thanks for the fantastic technical blog post.

Regarding the slow read operation from the frame buffer, there are cases when the user may want this. The obvious use case is capturing screen shots (eg. video recording). Another benefit is to allow the app server to do view compositing and the client can read this. For my video editor for Haiku, since I never had the ability to read the AppServer frame buffer, I ended up having to manually compose a scene in my own framebuffer (replicating painter functionality), forcing me to use OpenGL. It’s slow since I have to read create an OpenGL frame buffer object, draw there, and read it for exporting. If I had access to the AppServer framebuffer, I could have avoided this duplicate code path. Oh well, when we get HW acceleration, it will probably be for the better for my app (and I also benefit from having GLSL shaders to modify the frame buffer).

I had a similar issue with the media kit sound mixer. Ideally as an app developer, I would have loved to pipe my samples to the sound mixer, then get them back for final processing (eg. to encode to disk when exporting a project). However, since the media kit doesn’t allow accessing the output of the System Mixer, I ended up having to duplicate that code as well. Sadly, I wanted to use OpenAL for 3D positional audio effects. Even though Haiku supports OpenAL, it doesn’t allow me to pipe the final sound output back into my application - again, forcing me to duplicate that code as well.

Anyhow, thanks for a great technical blog post.

It should be possible to insert node between mixer and hardware. If this is not working it is a bug and it should be fixed.

1 Like

Date of this blog post is 2011-06-15, it posted about 10 years ago. Anyway, it contains a lot of useful information about graphics system implementation.

Personally I don’t like compositing because it consume much more memory and make system less responsible. I like lightweight and responsible Haiku.

1 Like

Some recent discussion about compositing:

Date of this blog post is 2011-06-15, it posted about 10 years ago.

Shows up as 4 hours ago on my system. Moving on …

I reposted the message because it had somehow been unpublished, possibly during a website update. It’s pretty much still up to date.

Regarding your comments: accessing the framebuffer seems possible, as both the “screenshot” tool and BeScreenCapture manage to do it. The API may not be straightforward and well-documented but you can look into how these apps do it.

As for view compositing, you can attach a view to a BBitmap and use app_server to draw offscreen if you need to.

For the mixer, I believe it’s also possible to instanciate your own mixer node if you want to reuse our mixer for other purposes than the final mixing step. While it should also be possible to insert a media node between the mixer and the soundcard, I’m not sure if that actually works. It’s possible the soundcard driver does not like its input being unplugged and replugged.

1 Like

I know this is an old conversation :persevere: but I was really hoping that Window Compositing would eventually be achievable in Haiku (for window shadows, non-rectangular window shapes and of course for my self-interested HiQDock) . @looncraz had some ideas too, but I see he’s not in this conversation so I’m adding him.

…adding @waddlesplash to grab your attention too :slight_smile:

I understand that this is a controversial feature/subject, but couldn’t it be disabled by default (or experimental build flag, etc).

Thanks for listening

1 Like

We already have “non-rectangular windows” with the default “tabbed” decorators, don’t we? So, we don’t need compositing for that.

It is not at all a priority for me in the slightest, I don’t expect to spend time on it, contract or not.


Does anyone know how the non-rectangular windows worked in Dan0? Did they add compositing to app_server? I don’t think so. The one thing I remember is the mention of a data structure called a skip list being part of the implementation. I suspect maybe for determining what window a particular pixel would hit (for mouse clicks and probably dirty region detection?)

Anyhow my point would be maybe some of those concepts can be resurrected in Haiku at some point. I do think window shadows and the possibility for some non-rectangular windows or drawing windows with some transparency would be nice. It does not necessarily require compositing though that probably makes it much easier but uses more memory. I do know someone (Diver I think) linked to the Serenity OS pull request to add non rectangular windows in another forum post, which did not use compositing. This work might also be instructive. EDIT: Actually maybe it was window shadows, not non-rectangular windows, anyhow…

Now with all that said this is not super important and should not be done in favor of more important work, but if someone wanted to play with it…


Cool - didn’t know - would love to see it in action if anyone knows which decorator to use / install (from where)

Totally understand!

1 Like

Exactly - just hoping to get more eyes on this topic and hopefully someone will pick it up.

On a related note: Long long ago there was a 3rd-party mac-like Dock app on Dan0 or Zeta, (for which I saw a video) that seemed to have fully transparent background - in the video the user moved the windows behind the dock’s transparent background… so I’m assuming Dan0 / Zeta had some way of doing this?

For my HiQDock which uses Qt Window - which has this API:

    setAttribute(Qt::WA_NoSystemBackground, true);
    setAttribute(Qt::WA_TranslucentBackground, true);  

So my question is: do you think that the above API needs window compositing support in Haiku - or could it be accomplished in a more easy-to-implement way?

Probably it was Dockbert Dockbert Questions - #3 by Diver.

No it wasn’t dockbert - but that is a good example screenshot in anycase (PhOS) where you see transparent areas - how was it done in PhOS?

You don’t need compositing to due transparency iirc, i think app server supports this in the drawing library already. I can’t recall the name of the drawing library haiku uses but it’s a very robust open source library that supports these kinds of features


It is called AGG.

Introducing limited compositing is planned as part of hardware acceleration support. Compositor surfaces will be used for OpenGL/Vulkan windows. It is required to get tearing-free rendering without VRAM-RAM-VRAM copy. No per-window compositor surfaces are planned.


You need the compositor for vframe sync correct ?

That is based on BRegion, which is only a list of rectangles. Good enough for our window tabs, but there is no way to do any kind of rounded shape or even a non vertical/horizontal border, especially if you want some antialiasing on it.

So, it depends on your definition of “non-rectangular”, I guess. We can do more than “made of one rectangle”, but nothing else than “is entirely made of rectangles”.

1 Like

Yes, compositor is required to avoid tearing on modern high resolution displays.