[haiku-appserver] Re: BScreen support

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 6 May 2005 14:18:57 +0200 (MEST)


Sorry for the lengthy reply...

> > 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?

I noticed that the screen rebuild becomes quite noticably slower when more
windows are on the screen. From what I understand of the code, a full
rebuild of all the layers clipping regions will happen when you move a
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. When the clipping needs to be rebuild for all layers on
screen, the screen coordinate version could be marked as invalid. 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. 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. When
the real clipping of a layer is requested in screen coordinates for any
drawing operation, it is that layers local clipping (which almost never has
to be rebuild) converted to screen coordinates, and than intersected with
its windows clipping. This clipping can be cached of course. I think with
these changes alone, the clipping rebuilding would be accelerated a lot, and
especially, it would "scale" a lot better with more and more windows on the
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. From all other windows which are currently not resized.
This has got to make the algorithm slower then necessary.
That being said, I am no guru for layers, clipping and all, but I think that
the things I just said would improve the algorithm a lot already. Everything
being open for discussion of course.
Ok, so how can you see what I mean by "bad scaling": Open two windows in our
app_server. Move one of them to the left, the other to the right. Now move
one window. Either try to remember how this feels, or time the clipping
rebuilding code directly.
Now do the same thing for a lot more windows. Say twenty. Move nineteen of
them to the left side of the screen, and move one to the right. Move the
right side window without going on top of the others, so that no drawing is
triggered. I think it feels differently, and I would be interested in the
actual timing too. The windows should have some views in them too, or like
real windows.

>       If it is a problem, it may be because in some cases a
> biger-than-required region is invalidated, or a more general target
> (WinBorder) is targeted, or because of a bug somewhere...

I think I understand exactly what you mean by "a more general target". It
will cause a lot more rebuilding, since it will travers a lot more of the
tree. But for window movement and resizing (the most common situations for
having to rebuild the clipping) the target is rightfully the window border,
and the rebuilding starts from the parent, the root layer. So it is done
(from the point of the current algorithm) rightfully for all other windows
currently on screen. But like I said, a lot of calculation can be skipped if
we consider local<->screen clipping.

>       In the little free time that I'm having, I'm writing a more clear,
> simplified version of the clipping code(/region rebuilding), but the
> algorithm
> is the same. I will write you about this code and share it with you and in
> the end I'm sure we'll come up with the best solution.

Maybe what I just described influences how you think about the design. In
any case, I'm looking forward to your improved version.

> > Otherwise it is a ridiculous discussion. And before we 
> > even worry about performance at all, we need a correct implementation. 
> > Anything else is premature optimization.
>       Do not agree. At least in the context of our discussion.
> A good design should be enforced from the start. If we did not
> had a SMP friendly design final optimizations could not get as
> much performance of a SMP machine if we did not take that into

Yes, I think we mean the same thing. But before you think about the design
being fast, you have to think about the design to be capable of doing all
the stuff you need from it. Just try to open the People app in our
app_server and you will be convinced, that the current design does not
behave correctly yet.
Maybe it will behave better, when you have rewritten it. Part of the problem
is the mix of resizing, moving with the clipping rebuild. Layers which have
not been added to the tree in a certain way will not be resized or moved at
all. Which I think is the reason for the People app looking like it does. I
fixed part of it with my recent check ins, but those are some "dirty" work
arrounds for problems in the current design. So the rewrite should consider

Best regards,

+++ Neu: Echte DSL-Flatrates von GMX - Surfen ohne Limits +++
Always online ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Other related posts: