This probably seems stupid

Could you rewrite the BWindowScreen class to become the root window? If so what would be required? I ask because it would seem to me that this class would provide a way to develop a compositing architecture that would be rendered from the hardware directly.

What do you think the “root” window is? It is just a window like the others. It just happens to be “always-on-bottom”, not movable/resizable. But it does not contain the other windows.

Our BWindowScreen implementation is doing everything in software. In fact, our frame buffer isn’t even stored directly in video RAM. If we want the hardware to render anything, we need a driver that can drive it.

Adding compositing to the app_server was already attempted however, and I’m sure you can find the relevant threads in the mailing list archive, and the prototype, probably in looncraz’s github. It needed a rework of the whole drawing system and the way windows are managed. In other words, compositing doesn’t happen inside a window, it is one layer above.

1 Like

I thought the root window was the “root” from which all other windows branch from.

But I thought that the BWindowScreen was rendered directly from the framebuffer? Would the driver be like the BAccelerator class or the Display class in the driver addons?

I read the article that he/she wrote and looked up the github project, but I couldn’t find anything.

In Haiku, applications can’t get a direct access to the video buffer in the video card. In BeOS, BWindowScreen allowed that, but in Haiku, it only gets you to the frame buffer stored in main memory.

When doing hardware compositing, there isn’t such a frame buffer or root window anyway. Each window draws into its own buffer, and then the buffers are composited by showing them as textures.

When I was talking about a driver, it was mostly that: a graphics card driver with some support for the 3D pipeline, able to set up some textures and quads and put them on screen. The compositing would then be built upon these simple primitives.

Thanks for the reply.

Couldn’t that be built into the NvidiaHardwareRenderer, or the RadeonHardwareRenderer add-ons of the OpenGLKit? Or is that just worthless?