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

["Stephan Assmus" <superstippi@xxxxxx>]

Hi,

> > I think that either way is fine. If you can make it so that 
> > everything 
> > is blitted which can be blitted, fine with me.
> 
>       Okay, I'll go that way. But we really need a well written 
> CopyRegionList().

I just talked with Ingo about it, and I think I understand his email 
now. Maybe I find some time to implement the topological sorting 
sometime soon.

> > What makes CopyBits() and probably CopyRegionList() different from 
> > the 
> > rest of the drawing methods in DisplayDriver, is that partial 
> > invalidation of some views might have to be triggered.
> 
>       Only for CopyBits().
>       CopyRegionList() is internaly used by app_server and needs not to 
> behave like CopyBits(). Moreover, CopyRegionList() never takes 
> regions/rectangles partialy non-visible, but only visible regions to 
> be 
> blitted on-screen and still be fully visble at their new location - I 
> mean CopyRegionList() _must not be_ clipped(/clipping_constrained) 
> (guess you get what I'm trying to say :-) ).

Yes, I fully understand. Of course, in your implementation, you would 
have to take care of BViews which are resized along with the window, 
some want B_FULL_UPDATE_ON_RESIZE.

I think I can do the preparation for CopyBits() myself. Unless I get 
the meaning of some of those regions wrong... :-}

> > So I would argue, that the correct clipping for these two 
> > methods should be done *before* calling CopyBits()/
> > CopyRegionList().
> 
>       Yup, completely agreed. By doing that, the rects (resulted by the 
> intersection of CopyBits()' rect with Layer's visible region, 
> translated 
> to the new position and then intersected again with Layer's visible 
> region) can be copied _without_ applying instruction clipping and HW 
> acceleration (blit) can be used.

Yep.

> > For the simple reason that these calculations have to be done 
> > anyways 
> > to know which parts of layers need a possible redraw.
> 
>       Yup, yup, yup. :-)
> 
> > Therefor I think 
> > that the CopyBits() and CopyRegionList() should have to do no 
> > further 
> > clipping,
> 
>       Yup, no clipping for them.

:-D

> > except for maybe watching out if copying out of frame buffer 
> > bounds (just as an exercise in writing error resistent code).
> 
>       Nah, no need for that.

Never trust the other parts of a big pile of code. I already 
implemented that, if you dare, you can comment out the safety code... :
-)

>       IMO, you can even eliminate CopyBits() as it's not needed AFAIK - 
> CopyRegionList() should become CopyRectsWithOffset() and just forward 
> the list to the accelerant.

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.

> > As for doing the in-place copy of all the rects in a BRegion in the 
> > correct order, I have already contacted Stefano in privat (because 
> > he 
> > wrote BRegion). If anybody else has an idea for a fast topological 
> > sorting algorithm, feel free to speak up! :-) 
> 
>       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)
> 
> Just a thought... :-)

It's pretty late here and I have had a drink or two, so I can't comment 
on that, but I will think about it in the morning... :-) Ingo has also 
explained his graph sorting algorithm, and I'm sure that it will work. 
Maybe your idea as well.

Best regards,
-Stephan