[haiku-appserver] HW CopyRegions and next steps

Hi all,

>       We should do that too for CopyRegions inside the HW accelerated
> version of DisplayDriver.

The thing you're missing here is that the back buffer needs to be up to 
date. Doing the CopyRegions in the front buffer is possible, but then 
you would have to transfer the changed area into the back buffer, so 
that the next drawing operations would be rendered on current data. 
However, the front buffer will obviously be in graphics mem, and the 
backbuffer will be in main mem, for the reasons already explained. 
Copying from graphics to main memory is definitely no option. Therefor, 
the CopyRegion has to be done in software (which not so slow at all!!! 
I'll come to that in a minute). And then the changed areas have to be 
transfered to the front buffer (which is much faster than having to do 
this in the other direction). So why was hardware accelerated 
CopyRegions invented at all? You need that when you _don't_ have a 
double buffered design. If you had no accelerated CopyRegions, you 
would have to do that in software _in graphics mem_, and that's what's 
so slow about it. Doing it in software in main memory is probably not 
that much slower than the accelerated CopyRegions in graphics mem. It 
is probably slower but that dramatic compared to doing it in software 
in graphics mem.

To sum up, we cannot use CopyRegions in the front buffer, and that 
means we cannot do it accelerated. 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.

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. This seems to be currently missing. 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).

* Maybe this is done to little extend, but update requests should 
culmulate more if the app_server is already busy. 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.

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.

Best regards,
-Stephan

Other related posts: