[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,
-Stephan
Other related posts:
