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