FreeLists / haiku-appserver / [haiku-appserver] Re: BScreen support

[Adi Oanca <adioanca@xxxxxxxxxxxxx>]

Hi,

Stephan Assmus wrote:
>>>P.S. About performance concerns: Some of the code that the RootLayer 
>>>thread executes scales pretty bad, for example the algorithm used for 
>>>rebuilding layer clipping. Before we worry about saving performance by 
>>>trying to make locking unnecessary, we need to worry about the 
>>>algorithm first.
>>
>>      Nah, the algoritm is just fine. I did some tests a while ago an it
>>seemed to perform pretty well. At least those ms were very few.
>>      I'm curios, what makes you say that?

        Now, I know.
        It _was_ performing good a while ago - when I first wrote it, but in 
the mean time I tried to make things simpler by cutting down a bit from 
performance. It appears I did that a bit too much :-) and currently you 
are right - it scales badly.

> window. I think the problem is that the clipping of a layer is in screen
> coordinates. Maybe it is smarter to have the clipping in local layer
> coordinates, with a screen coordinates version that is calculated on the fly
> and then cached.

        I did thought about the clipping region being in local coordinates it 
appears you have to do a lot of transformations during region rebuilding 
(every parent must its children visible regions to exclude them from its 
own) and while searching where a point falls in a layer tree. Caching 
can be a solution here... Another problem is when clipping drawing 
instructions because the local clipping region needs to be transformated 
in screen coordinates. Caching can be a solution here too, but as I see 
it it's just the same amount of processing as when keeping clipping 
regions in screen coordinates. IMO screen coords is the way to go.
        Nevertheless, I/we will try this approach too. It's not difficult to 
write and doesn't take a long time.

> Note that
> windows and normal views should be treated differently. For overlapping
> sibling views, no clipping is (nor should be) considered, only the child
> views are clipped from a views visible area. In that sense, the local
> clipping of a view does not have to be rebuild at all, only when child views
> actually change or the view itself is resized.

        I am getting something from the text above, but not all. :-)
        Here's my version:
        You start with a region, let's say a window's one. All children can or 
cannot be overlapped. Suppose we have 10 layers and we move the 5-th one.
        All we can take for sure is the visible region of the window _and_ all 
children and ancestors it has - that's what I call fFullVisible. Because 
the 5-th layer move, something _can_ be changed in our 
window's(WinBorder's more correctly) visible region, we simply don't 
know if the region from there th 5-th layer will be leaving from will be 
  include in window's visible of in other child's fFullVisible region.
        For that reason we invalidate window's visible region by making it 
equal to its fFullVisible and start cutting from it children's ones 
starting from the most visible and ending with the backmost one. Now, we 
don't need to rebuild the visible region of the first 4 layers because 
they were not affected by the move of the fifth, all we need to do for 
them is exclude their fFullVisible regions from window's visible one. 
We'll start the rebuilding process from the 5-th layer and we will 
rebuild all the remaining ones (5) _if_ their fFullVisible region 
intersects the region from where the 5-th layer left from.

> For windows this is
> different. Windows never have siblings, instead they are all stacked. So I
> think it makes sense to account for this difference in the algorithm.

        Sorry, I don't get what you mean.
        I don't see any difference between windows and views. Windows are 
staked but their order can change, views are stacked but their order 
cannot change.
        It's true that windows don't have siblings but Layer/RootLayer's 
VirtualXXXXX[Child/Sibling]()s methods give that illusion.

> screen. And there is another thing. When a window is resized, which is
> usually the situation that causes child layers resizing, the moving and
> resizing code is in the same algorithm that rebuilds all other visible
> layers clipping.

        I managed to have them separated in this new version. :-)


bye,
Adi.