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

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 26 Apr 2005 16:10:16 +0200 CEST


> >>    IMO, you can even eliminate CopyBits() as it's not needed AFAIK 
> > > - 


> >>CopyRegionList() should become CopyRectsWithOffset() and just 
> > > forward 
> >>the list to the accelerant.

Yeah, eventually I will extract the sorting to be used for the 
accelerated version as well.

> >>    I have an idea, but I never tested it or checked for 
> > > correctness.
> >>    Let's take the N-W -> S-E resize mode. One can create a list of 
> >>rectangles ordered by rect.left*rect.top*offset.x*offset.y ( == 
> >>destRect.left*destRect.top) and blit rect by rect starting from the 
> >>end 
> >>of the list.
> >>    Analogically, for other resizing modes. (Using other corners)

I have used Ingos algorithm, since your idea does not consider the size 
of rectangles. For example:

      *        *
      *        *
      *        *
      *   B    *
      *        *
      *        *
 ******        *
 * A **        *
 *   **        *
 ******        *

B should be copied first for N-W -> S-E direction, but A.left * A.top 
can be a larger number than B.left * B.top if A.top is big enough.

> > 
> > Yes, there will be CopyRegion() and CopyRegionList() which uses the 
> > first. There won't be a CopyBits() in DisplayDriver anymore.
> > CopyRegion() will do the topological sorting of the rects and call 
> > some 
> > internal worker function to do the actual inplace copy of a rect.
>       I don't think that is a good idea. One must apply the topological
> sort on all the rects that are to be blit. For that reason I think
> CopyRegionList() must be the one to do the sort. You cannot blit 
> rects
> of a region and then continue with the next region, that may overlap/
> overwrite
> rects that still need to be blit.

I have not implemented it in this way yet. I do understand what you 
say, but I'm not sure the sorting will work for multiple BRegions 
copied with different offset each. Maybe CopyRegionList should assume 
the list of BRegions is already sorted itself, so that even if 
overwriting takes place, it takes place in the right order and does no 

Next up: I will see how far scrolling is implemented as of now.

Best regards,

Other related posts: