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

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Hi Stephan,

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

I don't think it does that, as "tearing" is still visible when you're 
moving around windows - and that shouldn't be visible if drawing occurs 
during the vertical blank.
Since transparency is very slow in Dano and flickers a lot, especially 
when crossing window borders, I think they might have a per window back 
buffer. That would also reduce the update work when moving windows 
around.

> double buffering in our current implementation also has nothing to do 
> with preventing flickering. That's two different things actually.

No, not really I think: I call it flickering when you ie. have to clear 
the background first, and then draw the text on top of it - that's what 
double buffering removes entirely. 
When that change is copied back into the frame buffer at once, there is 
no flickering - what you might see is some "tearing" when the refresh 
happens in the copied region.

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

Yes, but that would make B_OP_OVER and friends again very expensive and 
slow, so that we might not want to do it this way (we'll see, I guess).

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

Nice.

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

I meant drag&drop transparency a.k.a. alpha blending, ie. when moving a 
couple of icons around in Tracker. It's not as common as drawing text 
with B_OP_COPY, but it happens very often nonetheless, and should 
therefore be fast.
That's actually one of the things that feels better in R5 as in Dano; 
but of course, I'd like to have both good things on Haiku, double 
buffering and fast alpha blending.

Bye,
   Axel.