[haiku-appserver] Re: HW CopyRegions and next steps
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 31 Mar 2005 15:49:13 +0300
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:
