[haiku-appserver] Re: [Haiku-commits] r12953 - haiku/trunk/src/servers/app

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 06 Jun 2005 20:50:53 +0200 CEST

Axel D=F6rfler wrote on Mon, 06 Jun 2005 18:19:20 +0200 CEST:

> Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> > > +// NOTE: I added this here and it solves the invalid region 
> > > problem
> > > +// for Windows that have been resized before they were shown. -
> > > Stephan
> > > +RebuildFullRegion();
> > > +SendViewCoordUpdateMsg();
> > > +
> > > + if (invalidate)
> > >           GetRootLayer()->GoInvalidate(this, fFull);
> > >  }
> >     You should, under no circumstances call RebuildFullRegion() from 
> > another thread than RootLayer's one. I can guarantee this can have 
> > very 
> > ugly consequences. For example try moving a window while you show/
> > hide 
> > another.
> 
> Okay, but how should it be done instead, then=3F
> 
> Also, if the app=5Fserver crashes, it's almost always in the layer code 
> - 
> I don't see any obvious bugs in there, so it seems to be a locking 
> problem. Those bugs were already there before Stephan's changes. Can 
> you have a look at it when you're done with the clipping stuff=3F

May I add that I have tried to understand the Layer tree traversal 
several times now, but I just don't get it. I also read over it several 
times in Adis new clipping code, which is a lot cleaner, because it 
doesn't have so much other stuff in it.
What is the adventage of doing it like it is done=3F Compared to using 
BList or something similar as a container for each Layers children=3F
That aside, the clipping calculation still looks like it might have to 
recalculate too much during each run. Here is some pseudo code which I 
have been rolling in my head (just typing it now, so please excuse 
obvious erros):

void
Layer::RebuildLocalClipping()
{
        fLocalClippingRegion.Set(Bounds());
        for (int32 i =3D 0; Layer* layer =3D ChildAt(i); i++) {
                fLocalClippingRegion.Exclude(layer->Frame());
        }
        fScreenClippingRegionValid =3D false;
}

const BRegion&
Layer::ScreenClipping(bool forceRebuild)
{
        if (forceRebuild || !fScreenClippingRegionValid) {
                fScreenClippingRegion =3D ConvertToTop(fLocalClippingRegion);
                fScreenClippingRegion.IntersectWith(Window()->ScreenClipping());
                fScreenClippingRegionValid =3D true;
        }
        return fScreenClippingRegion;
}

[This code takes the fact into account, that sibbling views don't clip 
each other. In BeOS, you just have to make sure that views on the same 
level don't overlap, or both are alowed to draw in the same area.]

Note that the local Layer clipping only ever changes if the Layer 
itself is resized or if there is a change with its children (add/remove
/show/hide/move/resize). When for example moving windows, this does not 
happen at all! What this code hides is the fact that the "dirty" region 
needs to be tracked as well during any changes. But I don't see any 
problems there. In any case, isn't this just much more straight forward 
as a basis for the real algorithm=3F Any insights=3F

Best regards,
-Stephan



Other related posts: