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.
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.
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.
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.
I know this is an old conversation 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.
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…
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:
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?
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
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.
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”.
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) . 