[haiku-appserver] Re: HW CopyRegions and next steps

Ola,

Stephan Assmus wrote:
> this in the other direction). So why was hardware accelerated 
> CopyRegions invented at all?

        I think I have explained what I wanted to do. In the end it seems
not to be possible for R1 as we don't have the required support in
accelerant interface.

> You need that when you _don't_ have a double buffered design.

        Yup. We didn't had that until you came with Painter.

> To sum up, we cannot use CopyRegions in the front buffer, and that 
> means we cannot do it accelerated.

        OK.

> However, I can think of some ways to 
> make this work, but it would make the design much more complicated. It 
> involves keeping track of "dirty regions" in the back buffer, which you 
> only transfer from the front buffer in certain situations. I think we 
> don't need to concern ourselfs with that right now.

        I don't know what to think about CopyRegions anymore.
        By using CopyRegions we can avoid center and right alligned views
from being redrawn completely, but only what's needed; yet I don't know how
much speed can we gain copying those regions and imposing a smaller
clippign region instead of using a bigger clipping region and completely
redraw those views, especialy that all it's done in main mem now.

> As a next step to bringing the app_server forward, we need to make the 
> update code work 100% correct. Here is how it needs to improve:
> 
> * Right now it is correct in enforcing the current layer clipping 
> region. Layers can never draw outside their region. Good.
> 
> * When it triggers an invalidation of a view, this views drawing should 
> be restrained to what the clipping region was at the time the 
> invalidation was triggered.

        Code is in place. This should work. If it doesn't, we have a bug.

> This seems to be currently missing.

        Hmm... I'll investigate that.

> If you 
> don't believe me, I can explain more. So the clipping of BView::Draw() 
> is current clipping region combined with old clipping region from when 
> the drawing was triggered (+offset if the view has moved meanwhile).

        That's how it is now.
-----------
void ServerWindow::DispatchGraphicsMessage(int32 code, LinkMsgReader &link)
{
        fWinBorder->GetRootLayer()->Lock();
        BRegion         rreg(cl->fVisible);
        rreg.Include(&fWinBorder->yUpdateReg); <<<--- region from when the 
update request was sent.

        desktop->GetDisplayDriver()->ConstrainClippingRegion(&rreg);
-----------

Oups, fWinBorder->yUpdateReg needs to be offset-ed when the window
position changes. Bug! :-P

> * Maybe this is done to little extend, but update requests should 
> culmulate more if the app_server is already busy.

        With the code I wrote yesterday, they do!
        But not when app_server is busy, when ServerWindow is processing
the updates coming from BWindow/BView.
        During this time RootLayer thread is pilling up invalid regions.
When the ServerWindow update is over, if needed, a new update request is
send to the client side.

> Even though I 
> accelerated the drawing alot today, it is still dragging behind and 
> performing all the updates even though they could be combined in 
> greater steps.

        We should see how this behaved on real hardware. And if that
happens, then we definitely have a serious problem.
        I already did what you described above, currently I don't see
from where I/we can squeeze more performance from the update code. Maybe
pulling out a BRegion(would get a (very)small speed increase) and improve
locking a  bit.

        This code was made in a hurry, but I was thinking about how it
should work for some time, so I think it's quite optimal. :-)
        I said that I will revamp the update code. Well, I just made
my future work a lot easier :-). What I will do, is keep this code, improve
it if I can find places where to do that, am make it _a lot_ more clear!
Some code simply _does not belong_ where it is now.

> Even with these outstanding issues, I think we can also work on other 
> parts now, like how our GUI controls work under our app_server and see 
> about missing or incorrect implementations in the messaging (Looper/
> Handler Window/View). We're making good progress and I'm confident we 
> can get this baby working.

        Yup.

        So, my agenda for short term goes like this:
1) finish these small issues we've been having with the update code.
2) resume work at window manager - very few things left to do.
3) Rearrange the update code.

after that, my old task which can be shared with other people, making
all BWindow/BView methods work.


bye,
Adi.

Other related posts: