Blockquote
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 
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 
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.
2 Likes
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…
6 Likes
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?
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
2 Likes
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.
13 Likes
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.
5 Likes
Semi-transparent window parts can be done with BDirectWindow and special visible region calculation. No per-window compositing is needed.
5 Likes
Can’t a BBitmap be used as mask for the shape of the window? That would be similar to how arbitrary shapes are achieved on X.
1 Like
I believe that was dockbert. I recall using it on r5.
True. There is an X terminal program that does transparency without compositor. Urxvt I think? It does this by taking a snapshot of the portion of the screen that it occupies, and renders that into its own frame. Pretty slick and lightweight. Works great in environments where you don’t drag windows around, like a tiling window manager, as the background snapshot would move with the window until it redraws upon placement.
Yes, there is just no easy to use API to do it. It’s not really a matter of complex implementation, just exposing it to apps in a convenient way.
2 Likes