[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 15:32:04 +0200 CEST
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.
Other related posts:
