Hi Stephan, Stephen Deken wrote: > In the clock app, amongst others, we have an 'offscreen' view and an > 'onscreen' view. The offscreen view performs the actual drawing while > the onscreen view composites the offscreen view into a BBitmap and then > draws the bitmap. I assume this is done to ensure that the drawing is > flicker-free. > > Is it planned to rework the compositing engine so that this is no longer > necessary? Something like B_BUFFERED as a view flag? Also, is it > planned to add alpha transparency to the windowing system? (Not for R1, > obviously, but in the future.) Flicker-free drawing is already effective when Haiku uses the VESA driver. In this setup, the app_server renders into an offscreen frame buffer that is located in the main memory. In the early days, app_server would copy the dirty screen region into the visible frame buffer (graphics card memory) every single time when a drawing command was issued. Meanwhile, it does this only when an "update session" is finished or when a view is not during an update. Usually, the app_server will send a client window a message that redrawing views is necessary. The window will eventually reply that it wants to start drawing views. This puts the app_server into a mode (for the affected window) which turns off any back to front frame buffer update. At the end of the update session, when the window has run the BView::Draw() hooks of all affected views, the app_server will copy the refreshed contents of the back buffer to the front buffer. As a result, the drawing is completely flicker free and also more efficient, plus it doesn't use any additional memory that wasn't already used. For the case that app_server is using an accelerated driver, I implemented a similar approach, but the back buffer is also on the graphics card memory instead of main memory. This makes drawing commands that need to do compositing a lot slower, but the memory copy operation from back to front buffer can also be done with an accelerated graphics card function. I have not enabled this mode though, since I was unable to test it properly. However, today I remembered that I still had an nVidia board among my unused computer parts, and I replaced my ATI X300 with this nVidia board (not sure which model, could be 7300). With the X300, I was having problems with very slow drawing, likely an MTRR setup issue, but I am not sure. With the nVidia board, I can now properly test this thing. I already discovered, that there are some graphics glitches which I need to fix, but the general idea works very nicely. In this setup, all the accelerated calls are still accelerated, only they work on the back buffer. Then there is the additional overhead of using another accelerated call to copy everything to the front buffer, with the benefit that everything is completely flicker free as a result. Once i have fixed the glitches, I will enable this mode. So I hope this answers the first parts of your question positively. :-) Note that no changes to client applications are necessary to have flicker free redraws in them, no special BView flag is needed. Dano/ZETA had BView::SetDoubleBuffering(), but this is also not necessary on Haiku. Adding alpha transparency to the windows is something which I would like to implement / be implemented at some point. It does require some changes to the model that the app_server uses, but I believe it has some benefits. For example, it makes expose events much cheaper, since they don't require the client to repaint views. If the compositing is to be hardware accelerated, an update to the accelerant API is necessary and at least one graphics driver needs to be adapted to implement and test the changes. So it is some work, but certainly not out of reach. Best regards, -Stephan