[haiku-appserver] Going "back" to partially hardware accelerated drawing

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 20 Apr 2005 09:30:33 +0200 CEST

Hi all,

I've been rolling this in my head for quite some time. I have given 
some arguments, why we could do anti-aliased drawing and still have a 
fast system. The important argument is, that the frequently used 
drawing commands don't need anti-aliasing, which is filling solid rects 
and drawing straight horizontal or vertical lines. But this same 
argument can be used to drop the two buffered design. Here is why:
Even if can make the drawing with the CPU in main memory as fast as 
accelerated drawing by the GPU in graphics mem (which I doubt) - there 
will always be the additional back to front buffer transfer. And 
Michael Lotz has brought up another important drawback... it's a 
question of who does the work, the GPU or the CPU.
So in the next couple of days, I wand to go back to a single buffered 
design, where the buffer is in graphics mem and where the three most 
important functions are hardware accelerated: drawing horizontal/
vertical lines, filling solid rects and blitting (CopyBits()). The only 
difference to R5 here is that drawing non-horizontal/vertical lines 
will not be accelerated. I don't think this will be a huge problem, 
because when I look at my screen just now, I don't see any of those.
As I said, anti-aliasing will be slower when it has to read from the 
frame buffer. BUT - Be was facing the same problem with their text anti
-aliasing. And I think we should take the same approach as they did. In 
B_OP_COPY drawing mode, the default mode, text is not anti-aliased 
agains the actual background, but against the current low color. Only 
in B_OP_OVER and some of the other modes, it is rendered against the 
actual background (frame buffer), and we can do just the same with our 
anti-aliased lines. There is probably situations where we can get away 
with that. In any case, I think that the adventages far outweight the 
drawbacks, and so I will do the necessary changes and see how it turns 
out. Doing that is actually very easy from a coding point of view, I 
just wanted to explain it upfront, so you don't think I'm insane when 
you see commit messages like "switched back to single buffered design 
again". That being said, this topic is of course still open for 
discussion if any of you see something I have missed.

Best regards,

Other related posts: