[haiku-development] Re: Offscreen and onscreen views

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 20 Oct 2008 20:26:14 +0200

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



Other related posts: