On 1/10/17, 12:25 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>Once we’re on the topic of layout performance, I’d like to point out some >observations that we had: > >1. Layouts happen twice. I think this is because both setting height and >width trigger a resize event. This pattern causes every layout to take >twice as long as it should. I’m not sure how to fix this. There is a setWidthAndHeight API if you can use it. That's what I was referring to as possible optimizations, but it might require tweaking the layout to cache certain values and I think some layouts need to set a width in order to determine height. >2. Layout happens on obscured objects. There’s logic in layouts which >cancels layout for objects which are not visible (as defined by the >visible property), but there’s lots of other cases where an object might >not be visible. This can cause a lot of extra layouts for invisible >objects. I’m not sure if this is something which should be handled in a >generalized way. The solution might be more problematic than the problem. >This was something we wanted to handle in Accordion. Only the active pane >really needs layout and we did it like this (in AccordionItemRenderView): In the regular Flex SDK, the Accordion was called a "Navigator". TabNavigator was another. These things cause large sets of widgets in child containers to appear or disappear. Implementers have to decide whether "disappearance" means just visible=false, or removeChild. There are some good arguments for removal from the display list. Because underneath, if you were to manually write the same code in native JS, I think you'd run into the same problem. If you keep a ton of widgets in the DOM, the browser is going to have to work harder. Did you rule out removal from the DOM? -Alex
