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

Hi,

Stephan Assmus wrote:
> 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.

        Current implementation already takes care of that. :-)

>>>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... :
> -)

        Believe me, you don't need that. The visible region of a view will
be clipped on screen edge - it must.

>>      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.

        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 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.

        Then chose the one that performs best. :-)


bye,
Adi.

Other related posts: