It use per-window compositing.
You misinterpreted my sentence, I was saying the compositing work that was done by looncraz in a branch is likely really out of date.
I agree compositing has a potentially high cost. Probably in theory shadows could be done without having to do compositing? But someone would have to see. The code might be quite complex.
Is it different from what we have in app_server? What are your thoughts on this proposal
@looncraz I couldn’t find your fork with compositing app_server, is it still online somewhere?
Would be interesting to know what do you think about this topic too.
At least Windows XP managed to get shadows without compositing. It is possible to draw shadows in the same way as cursor and drag&drop image.
2 Likes
Hi @tqh, the code is here: GitHub - unarix/haiku_darkstyle: Haiku-os ControlLook & Decorator for darkFlat, moonFlat and lightFlat UI mode.
The ControlLook appears to work ok, but the problem is the decorator (haiku_darkstyle/FlatDecorator at master · unarix/haiku_darkstyle · GitHub), i dont know why after selected nothing happens.
So, to ensure that the problem is not my code, i compile the BeDecorator (haiku/BeDecorator.cpp at 8f16317a5b6db5c672f331814273e5857555020f · haiku/haiku · GitHub) using the sames includes that are in my repo. After selected all systema fall in debuggerland whith a sement violation.
1 Like
I made an illustration of my 3D hardware acceleration architecture proposal:
It introduce new native Haiku API for rendered buffer producers and consumers. It works in a way similar to Media Kit. Application that will render 3D graphics with OpenGL or Vulkan will expose BufferProducer interface that can be connected to BufferConsumer interface providers such as screen of compositor that will mix multiple inputs to one output. Connection is represented by SwapChain object that owns rendering buffers and control buffer swapping process. Connected BufferProducer and BufferConsumer may be in separate processes.
OpenGL or Vulkan applications are not required to have a window, it may be connected to another process BufferConsumer or to some offscreen processing BufferConsumer such as video recorder or network transmitter.
One screen-global surface is used for app_server 2D graphics so changes to app_server architecture and increase of resource usage would be minimal. app_server will provide clipping information to compositor by reusing BDirectWindow mechanism.
Applications do not directly talk to a compositor, it can request BufferConsumer interface for BWindow, BView or BScreen instead.
18 Likes
Yes. app_server use global rendering buffer and non-intersecting region clipped drawing areas. The same approach is used in Mac OS Classic, Windows 1.0 - XP, X11 without compositing.
This approach attempts to introduce mandatory per-window compositing and client side 2D rendering. It will require major rework of app_server and libbe.so. app_server will need to be rewritten almost from scratch. It may cause difficulties with printing and remote desktop because of client side 2D rendering instead of sending vector drawing commands to app_server. Because of per-window compositing it will cause significant increase of memory usage.
6 Likes
This is interesting, but probably should be its own topic?
3 Likes
I did a core dump from debugger with the one in HaikuDepot. I’ll see if I can use that core dump when the UI is running properly. Travelling around though, so little time for computers. Thanks for the detailed info.
Thanks for the help @tqh! Maybe @jscipione or @nephele can help too, i think that not too much time ago they made some changes in the api (if I remember correctly)
Thanks @leavengood! I downloaded the wallpaper from internet, so i think that i can share it: https://tinyurl.com/en78xjsb
Thanks. I did manage to track down a copy but this one is higher resolution.
Keep up the work on the control look and decorator I think they are a good option to have for Haiku. I will be out of town for a bit but when I get back I can see if I can help on the decorator crash. Good idea to test with the BeDecorator, if that is crashing something is definitely going on 
1 Like
The decorator is working again!
14 Likes
Good to hear that you got it to work again. I messed with ControlLook slightly but I did not touch decorators or app server.
1 Like
Im working in an old mockup that “integrate” the menu to the decorator. At the moment im here:
But, one problem persist: Exist any way to know in the controlLook who is the active window?
8 Likes
It’s probably easier to make the controllook change the appearence of menus, they can be in a lot of places, they just usually are at the top of the window.
1 Like
You should be able to call view->Window()->IsActive() from the control look to determine whether or not the window is the currently active window (i.e. the one with a yellow tab.)
1 Like
We need compositing in app_server to display drop shadows around windows. Window drop shadows could be implemented using software 3D acceleration without needing 3D accelerated video drivers. This would be an important step once we do have them.
However like so many things somebody has to do that work and it’s a major change to app_server drawing which makes it a daunting task.
2 Likes
This should be the new default decorator, for sure.
I am planning to propose we bundle this with Haiku, but that we give the user the option to choose which one they want to use.
1 Like