[haiku-appserver] Re: update code.

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: AppServer <haiku-appserver@xxxxxxxxxxxxx>
  • Date: Fri, 01 Apr 2005 15:22:10 +0300

Hi Stephan,

Stephan Assmus wrote:
> Read in BeBook BView::CopyBits().
> MyView::ScrollBy(float x, float y)
> {
>       BRect bounds = (Bounds());
>       CopyBits(bounds, bounds.OffsetBySelf(x, y));
> }
> Two things happen here. The BViews contents are shifted by x and y. BUT 
> what happens with the area, that was previously no within Bounds()? For 
> this area, the app_server triggers an invalidation and therefor Draw() 
> to be called (all automatically).

        Of course.
        As you might have already noticed there isn't support for that, yet.
        Not even BView::Bounds() is working. :-P (Tried a quick fix, but
that didn't work)

> What I'm saying in my above paragraph 
> is, that DisplayDriver cannot do this job for you.

        Yes, I know(understand), app_server must copy up/down what remains
visible and then issue an update request for the region becoming visible.

> is something you cannot do anyways. I'm further saying that the 
> accelerant hook does not do the clipping, but it can however be done in 
> DisplayDriver before passing it on to the accelerant.

        No, clipping is not needed for CCR() as those regions are _exactly_
what is needed to be copied.
        CCR() is never used by ServerWindow for instructions coming from
client-side, it is meant to be used by the app_server core only to avoid
sending an update request with a full redraw.

> No, read above. It can perform the clipping, but you need to be aware 
> of the BView regions that would need to be ivalidated inside app_server 
> anyways. So what you _cannot_ do is to just call the DisplayDriver 
> method with the parameters comming from the client, even if 
> DisplayDriver would perform the clipping for you. That's because then 
> you don't know which regions you need to trigger invalidation for.

        I think what I said above clears this up.

> And that's correct. Ok, I hope you understand what I mean by in-place 
> copy and what I mean by overlapping.

        Yup, now I do. :-)

> overlapping. In this case, the destination area overlaps the source 
> area in memory, but that is _no_ problem when you take that into 
> account in your copy algorithm. And I think this is what the graphics 
> engine in the accelerant is doing as well. It does not copy to out of 
> screen regions and then back into visible region at the offset. Unless 
> Rudolf convinces me otherwise... :-)
> I'm not saying it should go away, I'm just saying that certain criteria 
> must be met for it to be implemented efficiently.

        I wrote that implementation because I needed it, and I know
it is _really_ BAD implemented but that's what I could come up fastest.
        I welcome _any_ kind of improvement, but I'd like to keep it
as it spears us from completely redraw center and right aligned BViews.

> Now, here is one 
> criterium: The regions that it gets passed should not overlap.

        The passed regions, no, do not overlap. However, their destinations
overlap them.

> void DisplayDriver::_MoveRect(BRect rect, BPoint offset);
> This function handles all the magic of doing in-place moving of the 
> rect and it handles also the case where the rect at the offset overlaps 
> the original rect. I have shown above that this is possible.
> What I'm saying now, is that in the cause of one CCR() call, as you 
> call it, this function (MoveRect()) should never have to be called for 
> the same source rect twice or more. Or else the graphics would be 
> completely screwed if you do in-place copying. Ensuring this by 
> app_server prior to calling CCR() is just much smarter.

        Aha, I think I get what you mean.
        For example if you resize by dragging right, first copy those rects
closer to the right and finish with the left most ones.

> And I'm telling 
> you, you need this logic in app_server anyways, or else you don't know 
> which regions of BViews need to be invalidated, because of the resizing 
> or scrolling (for which this CCR() thing is meant to be in the first 
> place).

        Nope. These regions are calculated correctly. I can tell you for
sure, that whatever can be copied is copied and the rest is redrawn. I
assure you this works as I heavily tested that code in the past. :-)

> Uff. That's a long mail. Sorry, but I hope all is clear now.

        Yup. Glad you brought this up!


Other related posts: