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

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

Hi Axel,

> "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).

I don't know hard facts about how the drawing implementation changed in 
Dano, but I would think it simply syncs drawing commands with the 
refresh, as I can still observe "flickering" in some occasions. The 
double buffering in our current implementation also has nothing to do 
with preventing flickering. That's two different things actually.
I'm not against a double buffered screen update, but I would do it 
differently from how it's done right now - in order to be able to use 
hardware acceleration. This means the back buffer would have to be in 
graphics mem. It would mean no change to an existing single buffered 
design, only that there is an additional front buffer in the gfx mem, 
which is updated during the screen retrace. That would avoid flickering 
to some extend.

> 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.

Yeah, it's a "runtime" switch now. No problem going back.

> I am especially worried about transparency issues (for drag&
> drop).

I think the text rendering in R5 is a good example, one would think it 
needs to read from frame buffer, but it only happens in less frequently 
used situations. As I said, I think the advantages of using hardware 
acceleration far outweight the disadvantages when having to do alpha 
blending. I think we can have an anti-aliased drawing backend that is 
just as fast as R5 for the most frequently used situations.

Best regards,

Other related posts: