Sure, How should I view the call count for LayoutManager.doPhasedInstantiation?
Do I simply capture a Memory Snapshot before-and-after transitioning to the view in question, then highlight these two snapshots, then click on the Find Loitering Objects icon? At that point what am I looking for (I don't see a LayoutManager Class in the Loitering Objects panel like I did in the Live Object panel)? ----- Original Message ----- From: "Alex Harui" <[email protected]> To: [email protected] Sent: Wednesday, October 23, 2013 2:17:06 PM Subject: Re: any techniques to spread drawing of screen over several frames? Well, those numbers mean that a lot of work is going on, but it is hard to say if it is excessive without call counts. Let's see what the FB profiler has to say. -Alex On 10/23/13 2:08 PM, "[email protected]" <[email protected]> wrote: >Thanks Alex, > >I searched, and I'm not using creationPolicy in the app. > >I'm using spark State, rather than a navigator view (such as spark >NavigatorContent). > >I do see in Scout that the LayoutManager.doPhasedInstantiation >(mx.managers) occupies 98% of the total time for the frame in question. >If I analyze the memory allocations, I see (for the specific frame in >question): > >LayoutManager.doPhasedInstantiation (mx.managers): Allocations = 63405 >(memory=19600 KB) > >which is broken down as: > >- LayoutManager.validateProperties (mx.managers): Allocations = 34210 >(memory=11327 KB) >- LayoutManager.validateDisplayList (mx.managers): Allocations = 25588 >(memory=7137 KB) >- LayoutManager.validateSize (mx.managers): Allocations = 3607 >(memory=1137 KB) > >I have no idea if this is good or bad, as something allocated may have >gotten deallocated via garbage collection (?). > >I've used FB profiler before, but I tend to got lost among all the data >and windows to the point where I don't know what's going on anymore. Is >there an easy way to extract the call count for >LayoutManager.doPhasedInstantiation for a specific frame (and how to >identify that frame in the first place)? > >I've started up the Profiler just now and it's exhibiting some odd >behavior. The timeline grows as expected, but even though my app is >running fine, the profiler shows no activity (the Memory Usage graph is >flatlined at 0 and the Live Objects table is empty). I tried on FB 4.6 >and 4.7, same result. It used to work fine on FB 4.6. Any idea what it >could be? The application path points to the correct bin-debug/Main.html >file... > >----- Original Message ----- > >From: "Alex Harui" <[email protected]> >To: [email protected] >Sent: Wednesday, October 23, 2013 12:20:11 PM >Subject: Re: any techniques to spread drawing of screen over several >frames? > >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 >frame. > >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". > >-Alex > >On 10/23/13 12:03 PM, "[email protected]" <[email protected]> >wrote: > >>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? > >
