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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 20 Apr 2005 13:06:55 +0200 CEST

"Stephan Assmus" <superstippi@xxxxxx> wrote:
> 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.

My main problem with this is not speed, as Dano/Zeta, for example feels 
much faster with anything drawing related than R5. My main concern is 
flickering, which is absent in Dano, but very much annoying on R5. 
Since Dano is so fast, I am not sure if speed will be our problem with 
double buffering, even if we neglect hardware acceleration at some 
level (although I've no idea how Dano does it).

> 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 

As you pointed out that reading from the frame buffer is that much 
slower than writing, I am not so sure I like this. Since it's simple to 
implement as you say, I'd say go for it, but be open to turn back any 
time. I am especially worried about transparency issues (for drag&


Other related posts: