flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: FlexJS Layout performance (was Re: [FlexJS] Do we have a similar invalidation/commit concept as with the old Flex SDK?)
Date Tue, 10 Jan 2017 21:45:23 GMT
Hi,

As we were discussing this in another thread. Wouldn’t layout be one of the things that
our invalidateSize() + measure() logic of the regular SDK would be beneficial.
Otherwise I bet some layouting operations would be executed serially and multiple times (sort
of executing the logic of “measure” after setting the width and then again after setting
height.


Chris

Am 10.01.17, 09:25 schrieb "Harbs" <harbs.lists@gmail.com>:

    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.
    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):
    
    		override protected function performLayout(event:Event):void
    		{
    			var collapsibleStrand:ICollapsible = _strand as ICollapsible;
    			if (!collapsibleStrand.collapsed)
    			{
    				super.performLayout(event);
    			} else // skip layout for viewport children
    			{
    				layoutViewBeforeContentLayout();
    				layoutViewAfterContentLayout();
    			}
    		}
    
    
    On Jan 9, 2017, at 6:41 PM, Alex Harui <aharui@adobe.com> wrote:
    
    > 
    > 
    > On 1/8/17, 12:31 AM, "Harbs" <harbs.lists@gmail.com> wrote:
    > 
    >> Interesting. This is new to me as well.
    >> 
    >> What’s interesting to me is that it seems like FlexJS should (mostly) not
    >> have this problem.
    >> 
    >> If I’m reading it correctly, it’s reading geometric properties from the
    >> DOM which cause the reflow. Since the vast majority of reads in FlexJS is
    >> actually on the flexjs wrappers around the DOM elements, most reads
    >> should not trigger reflow.
    >> 
    >> The only major exception which comes to mind is the use of DisplayUtils
    >> methods which use getBoundingClientRect() and the like.
    > 
    > Maybe.  This definitely needs more investigation. Some layouts just set
    > browser styles and properties and never need to read back anything.  But
    > some layouts I think do ask for parent or child sizes via
    > offsetWidth/Height.
    > 
    > -Alex
    > 
    
    

Mime
View raw message