[haiku-appserver] Re: Going "back" & clipping
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 21 Apr 2005 12:08:19 +0300
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:
