[haiku-appserver] Re: Going "back" & clipping
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 20 Apr 2005 23:07:49 +0300
Hi,
Stephan Assmus wrote:
> 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().
> 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 :-) ).
> This is
> obviously something that DisplayDriver cannot be responsible for taking
> care of.
Fully agreed. For BView/Layer::CopyBits() app_server will issue an
update request if needed.
> 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.
> 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.
> 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.
IMO, you can even eliminate CopyBits() as it's not needed AFAIK -
CopyRegionList() should become CopyRectsWithOffset() and just forward
the list to the accelerant.
> 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... :-)
bye,
Adi.
Other related posts:
