Listen to the LayoutManager. I think the code is
LayoutManager.getInstance().addEventListener("updateComplete",...)
On 10/23/13 5:09 PM, "[email protected]" <[email protected]> wrote:
>Thanks Alex, silly question... what component should the listener for
>updateComplete be attached to?
>
>I don't think it's possible to attach it to a state.
>
>Should I pick some component that is included in myViewState1, for
>example?
>
>I would use
>
>this.addEventListener(); but there other states in this view, and I don't
>want this to effect them.
>
>----- Original Message -----
>
>From: "Alex Harui" <[email protected]>
>To: [email protected]
>Sent: Wednesday, October 23, 2013 4:47:34 PM
>Subject: Re: any techniques to spread drawing of screen over several
>frames?
>
>You can listen for an updateComplete from the LayoutManager itself to
>know
>that things have settled down.
>
>Don't use visible or includeInLayout, that still instantiates and
>validates components. Use excludeFrom and/or includeIn.
>
>-Alex
>
>On 10/23/13 4:26 PM, "[email protected]" <[email protected]>
>wrote:
>
>>Suppose I take the trick below to divide the view up into two states,
>>such that half of the original first state's components are drawn in the
>>first state, then some time later, the other half of the components get
>>drawn.
>>
>>How could this second state be called after the first state is drawn? I
>>don't think there's a creationComplete available for spark states... not
>>sure what else I could use.
>>
>>Also, for this trick to work, would half of the components be set to
>>visible=false in the first state, and all the components be set to
>>visible=true for the second state?
>>
>>----- Original Message -----
>>
>>From: "Alex Harui" <[email protected]>
>>To: [email protected]
>>Sent: Wednesday, October 23, 2013 3:25:28 PM
>>Subject: Re: any techniques to spread drawing of screen over several
>>frames?
>>
>>Also note that, sometimes, 23 is the right number. If you have several
>>HTTP requests coming in with data to fill combobox dataproviders with
>>the
>>list of cities, categories, etc, you may end up getting invalidated for
>>each results event.
>>
>>-Alex
>>
>>On 10/23/13 3:21 PM, "[email protected]" <[email protected]>
>>wrote:
>>
>>>Thanks Alex, you've been very helpful. I can't say I know enough to fix
>>>it, but I can understand the complexity of the problem.
>>>
>>>----- Original Message -----
>>>
>>>From: "Alex Harui" <[email protected]>
>>>To: [email protected]
>>>Sent: Wednesday, October 23, 2013 3:10:07 PM
>>>Subject: Re: any techniques to spread drawing of screen over several
>>>frames?
>>>
>>>In a very simple app, clicking on a button might generate one call to
>>>doPhasedInstantiation, and creating the new view should generate 1 to 3
>>>more so that's a total of 4, not 23. An idle app does not generate
>>>calls
>>>to doPhasedInstantiation. Moving a mouse over rollOver targets can,
>>>though, so be careful with moving the mouse when taking snapshots.
>>>
>>>Sometimes a more complex view assigns data that came in asynchronously
>>>and
>>>that will generate another 3, bringing you to 7.
>>>
>>>So now, it is time to justify those other calls. You can try setting
>>>breakpoints in the debugger and see what is in the priority queues, you
>>>can monkey patch LayoutManager, uncomment all the trace statements and
>>>get
>>>sort of a dump of what happened, or you can keep analyzing the
>>>snapshot.
>>>I look for updateDisplayList call counts next. There should be one per
>>>visible component. Anything else is essentially wasteful.
>>>
>>>One customer was binding widths and heights to widths and heights of
>>>other
>>>things, which causes excess laying out. Another customer was using a
>>>third-party application framework and a third-party string resources
>>>library that did its work on creationComplete which also triggered
>>>excess
>>>layouts.
>>>
>>>HTH,
>>>-Alex
>>>
>>>
>>>On 10/23/13 2:52 PM, "[email protected]" <[email protected]>
>>>wrote:
>>>
>>>>Thanks Alex,
>>>>
>>>>It shows 23 calls to LayoutManager.doPhasedInstantiation.
>>>>
>>>>Note that I clicked "Reset...", then clicked the button that switches
>>>>the app to the new view state, then waited for the state to display
>>>>completely
>>>>on the screen, then clicked "Capture...". I'm sure there were many
>>>>frames
>>>>that occurred between clicking "Reset..." and "Capture...", one of
>>>>which
>>>>was the
>>>>long frame in question. Not sure how to isolate the capture to that
>>>>particular long frame
>>>>in question ... should I worry about this?
>>>>
>>>>----- Original Message -----
>>>>
>>>>From: "Alex Harui" <[email protected]>
>>>>To: [email protected]
>>>>Sent: Wednesday, October 23, 2013 2:37:50 PM
>>>>Subject: Re: any techniques to spread drawing of screen over several
>>>>frames?
>>>>
>>>>You want to do performance profiling instead of memory profiling in
>>>>the
>>>>FB
>>>>profiler.
>>>>
>>>>Can you control when the code you want to profile will run? Maybe by
>>>>clicking a button or something?
>>>>
>>>>When you launch the profiler, check both the memory and performance
>>>>boxes,
>>>>then the app should start up. In the profiler perspective, there
>>>>should
>>>>be two tabs in the upper right "Profile" and "Saved Profile Data" and
>>>>next
>>>>to that are a bunch of icon buttons. One has the tooltip "Reset
>>>>Performance Data" and the other is "Capture Performance Profile".
>>>>Click
>>>>the "Reset..." button then hit the button in your app that will run
>>>>the
>>>>code, then go back to the profiler and hit the "Capture..." button.
>>>>That
>>>>should put a performance snapshot in the "Profile" tab that you can
>>>>double-click to view, and that has call counts.
>>>>
>>>>On 10/23/13 2:29 PM, "[email protected]" <[email protected]>
>>>>wrote:
>>>>
>>>>>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?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
