[haiku-appserver] Re: Going "back" & clipping

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 20 Apr 2005 12:07:47 +0300

Hi,

        Stephan, what feels 'good' should be done if there are enough
arguments for it. It this case there are enough, so go ahead and do the
right thing.

        That mail you sent to this list about how clipping code is implemented,
put me on some thoughts. As I have a deep understanding of that code, I think
I'll try to modify it so that it can be more clean and easy to 
understand/maintain.

        That will affect performance though. I've thought about it a bit and
I think the performance hit will be quite small, almost negligible(I think).

        Now, I want to discuss another thing with you guys so that I know
on which path to get going. In R5' when you resize a window, center and right
aligned views are fully invalidated, although some of their surface can
be easily blit and only what becomes visible should be drawn.
        In the current implementation I chose to "blit" anything possible, and
because of that I implemented CopyRegions which you all know uses a backbuffer
to copy regions to different locations. This is not optimal at all, and should
be done differently. Stephan proposed app_server should order the rects so that
they can be HW accelerated. But, we don't have that method at hand ATM...

        Now, I'm asking you: which path should I get onto? The first one, where
we have to completely redraw the center and right aligned views, or the second
one where we blit all what we have, and draw only what's new?

        Depending the of which method we chose the performance hit would be
greater or smaller (compared to the current one) for method 1, 2 respectively.
        As Be chose the first one, and as I did not hear anybody to complain 
about
R5's speed, I think we should chose the first version and leave the possibility
open for improvement by adopting version 2.

        What do you guys think?


Stephan Assmus wrote:
> Hi all,
> 
> 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.
> So in the next couple of days, I wand to go back to a single buffered 
> design, where the buffer is in graphics mem and where the three most 
> important functions are hardware accelerated: drawing horizontal/
> vertical lines, filling solid rects and blitting (CopyBits()). The only 
> difference to R5 here is that drawing non-horizontal/vertical lines 
> will not be accelerated. I don't think this will be a huge problem, 
> because when I look at my screen just now, I don't see any of those.
> 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 
> just wanted to explain it upfront, so you don't think I'm insane when 
> you see commit messages like "switched back to single buffered design 
> again". That being said, this topic is of course still open for 
> discussion if any of you see something I have missed.
> 
> Best regards,
> -Stephan
> 
> 
> 


Other related posts: