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.