"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& drop). Bye, Axel.