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