flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: any techniques to spread drawing of screen over several frames?
Date Wed, 23 Oct 2013 19:20:11 GMT
I still haven't used Scout.  I have used the FB Profiler so I'm just more
used to it.  Probably time for me to try Scout.  Anyway, the first thing I
would check is the call counts.  I heard you may not be able to get that
from Scout so you may need to use FB.

Try to get the call count for LayoutManager.doPhasedInstantiation for that
frame  It should be a small number like 3 or 4.  If it is higher, then
there is extra invalidation going on that, if you can eliminate it (and
you can't always) could drastically affect the execution time of that

A new navigator view should switch the LayoutManager to phased
instantiation mode and spread the validation across multiple frames so
mouse cursor doesn't stick.

Also make sure you are not using creationPolicy="all" in any navigators.
That is always a performance killer.

Only instantiate components that are visible.  Postpone instantiation of
components that aren't.

You can use various tricks like changing states to incrementally add more
components to the screen.

You can use modules to load whole sections of UI "later".


On 10/23/13 12:03 PM, "modjklist@comcast.net" <modjklist@comcast.net>

>One of the views in my app takes a few seconds to appear on the screen.
>During this time the mouse icon appears frozen (recovering after the
>screen is fully drawn).
>Profiling with Scout, I can see the related frame, which, this one frame,
>takes a couple seconds to complete. I'm guessing this is due to a fairly
>complex view to layout and draw.
>When I implement a stopwatch timer throughout the ActionScript code, the
>times spent within the functions are negligible. So I'm guessing most of
>the time is spent behind-the-scenes somewhere drawing things.
>I tried using callLater() in various places, but this just led to
>problems since it changed the intended execution order of the code.
>Are there any techniques to force this drawing to occur over several
>frames so the mouse doesn't appear frozen to the user? 

View raw message