[haiku-development] Re: Question About Accelerated Drawing Functions

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 14 May 2008 22:32:17 +0200

Gerald Zajac wrote:
> While testing the new S3 Video Driver, I happened to notice that the 
> accelerated drawing functions are used only when the color depth is 32 
> bits.  I'm wondering why the accelerated drawing functions are not used 
> when the color depth is 8 or 16 bits.  Since the S3 driver supports 32 
> bit color on only the Savage chips, it would be nice to have accelerated 
> drawing for the Virge and Trio chips where the driver supports only 8 and 
> 16 bit colors.

The reason is that app_server has to do a lot of drawing itself, for which 
there are no accelerated driver functions. It was the easiest way to only 
implement all that drawing stuff for 32 bits. For drawing on non-32 bit 
surfaces, I am simply using double buffering, where the drawing (back) 
buffer is converted to the color space of the visible (front) buffer on the 
fly.

At first, I did this because I wanted to get everything working sooner. But 
after some experience with graphics memory <-> main memory and color space 
conversion, I am wondering if what I am doing now isn't the more efficient 
solution anyways. When doing this "properly", with real support for the 
other colorspaces, the conversion would go in two directions, instead of 
one, and there would be reads from video memory. So while solid fill rects, 
rect inversion and copy bits would be faster on very old hardware if the 
graphics card does this instead of the CPU, any other drawing (for example 
text rendering) will definitely be much slower then it is now. If not for 
the additional overhead of more conversion, then definitely because of 
reading the video memory. Another pro argument for doing the double 
buffering is that Haiku is then almost flicker free, since it delays any 
back to front copies until a BView finished drawing. When rendering text 
against a background for example, this means the same area is only written 
once to the video memory.

At the moment, I don't have a good overview of how these pros and cons 
would balance on an old system. What is your impression, how does Haiku 
feel on such hardware without acceleration?

> BTW, I plan to submit this S3 driver in a few days.  I have completed 
> testing on the hardware that I have, and have asked a few other people to 
> test it on hardware that I do not have.  If they do not find any 
> problems, I will submit the driver source code to the project.

Nice! Thanks for all your work on this!

Best regards,
-Stephan


Other related posts: