The code looks familiar, but I'm not 100% sure.
The trick with layouts is that there are the following things to consider:
If everything has an explicit width/height, it should be pretty easy.
The percentWidth/height when present changes the _width, _height without
changing the explicit size. This allows a layout to work again on the
percent value and calculate a new size. If the explicit sizes are set,
then the next layout pass will take the explicit over the percent (setting
explicit sizes sets the percent sizes to NaN and vice-versa) and what was
once 50% will now be fixed in size.
The tricky part - for me anyway - is when an item has no size set. Then
its supposed be sized by its content. Labels and Buttons sized by their
text or icons while containers are sized by their children and so forth.
Let's say you have one container nested inside of another and in the inner
most container is a single button. The outer most layout cannot determine
its container-child's size because it doesn't have one yet. The inner
container needs to get the size of its children (the button) and that then
becomes its size. But it should not be setting the explicit sizes. That
allows the button to be resized which means its container becomes bigger
which means the outer container becomes bigger. Once you set those
explicit sizes, then its game over - use case #1 essentially.
So - I think that code has to do with determining size-by-content and so
isLayoutRunning was created to prevent a recursion.
For me, working with Flex and Royale - determining the size of something
has been one of the biggest challenges.
‹peter
On 3/23/18, 7:46 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>I¹m working on making layouts more efficient. Currently, there¹s lots of
>setting and reading of width and height which causes many browser
>reflows. While profiling performance in my app, reflows is a major
>bottleneck. In one area, it¹s taking about 150ms (on my I7 2.8 Ghz
>MacBook Pro ‹ on tablets it¹s painfully slow) to execute on area of
>layout. Almost all of that time is being spent measuring with and height
>of components. The width and height getters trigger reflow because
>properties are recursively set in layout.
>
>I was able to get about a 10% improvement by optimizing the width and
>height getters to return the explicitWdith and explicitHeight if set. It
>looks to me like almost all of this bottleneck could be eliminated by
>delaying the property setting until after the measurements are done. I¹m
>working on doing that, but I have a question:
>
>LayoutBase.performLayout has the following code:
>
> // check sizes to see if layout changed
> the size or not
> // and send an event to re-layout
> parent of host
> if (host.width != oldWidth ||
> host.height != oldHeight)
> {
> isLayoutRunning = true;
> host.dispatchEvent(new
> Event("sizeChanged"));
> isLayoutRunning = false;
> }
>
>Under what circumstances does this code get executed? This appears to be
>causing a recursive layout. Can I assume that there will be an
>explicitWidth/height when this will be executed?
