Zenja
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.
1 reply