You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by mo...@comcast.net on 2013/10/23 21:03:35 UTC
any techniques to spread drawing of screen over several frames?
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?
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
Ahh, I closed the Adobe Scout application and now the Flash Builder built-in profiler works fine. Go figure...
----- Original Message -----
From: modjklist@comcast.net
To: users@flex.apache.org
Sent: Wednesday, October 23, 2013 2:08:11 PM
Subject: Re: any techniques to spread drawing of screen over several frames?
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net>
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?
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
Both Scout and the FB Profiler should be able to show you the top most
expensive functions. If you post a screen shot we can see if there is
anything unexpected in there. Usually it is just more LayoutManager
methods and when you get down to specific component methods it is a low
percentage, but you never know.
On 10/23/13 5:39 PM, "modjklist@comcast.net" <mo...@comcast.net> wrote:
>In Scout, the Summary panel shows:
>
>Total Frame Time = 1601 ms
>ActionScript3 = 1443 ms
>DisplayList Rendering = 25 ms
>Other = 131 ms
>
>----- Original Message -----
>
>From: "Maurice Amsellem" <ma...@systar.com>
>To: users@flex.apache.org
>Sent: Wednesday, October 23, 2013 5:21:45 PM
>Subject: RE: any techniques to spread drawing of screen over several
>frames?
>
>Hi,
>In Scout, you can the breakdown of rendering vs actionscript for that
>particular 2sec frame.
>What are the values ?
>
>Maurice
>
>-----Message d'origine-----
>De : modjklist@comcast.net [mailto:modjklist@comcast.net]
>Envoyé : jeudi 24 octobre 2013 02:12
>À : users@flex.apache.org
>Objet : Re: any techniques to spread drawing of screen over several
>frames?
>
>That's a good suggestion Mark. I tried turning various components
>invisible, which didn't have any impact really. But it sounds like I
>should have used excludeFrom or includeIn instead. I can try again.
>
>----- Original Message -----
>
>From: "Mark Fuqua" <ma...@availdata.com>
>To: users@flex.apache.org
>Sent: Wednesday, October 23, 2013 4:57:17 PM
>Subject: RE: any techniques to spread drawing of screen over several
>frames?
>
>I am pretty clueless and don't want to imply anything different, but
>could you just comment out a bunch of components, then some others,
>narrowing it down...keep running the test until you see a spike?
>
>Mark
>
>-----Original Message-----
>From: modjklist@comcast.net [mailto:modjklist@comcast.net]
>Sent: Wednesday, October 23, 2013 7:27 PM
>To: users@flex.apache.org
>Subject: Re: any techniques to spread drawing of screen over several
>frames?
>
>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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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" <ah...@adobe.com>
>>>>>To: users@flex.apache.org
>>>>>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, "modjklist@comcast.net"
>>>>><mo...@comcast.net>
>>>>>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?
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
In Scout, the Summary panel shows:
Total Frame Time = 1601 ms
ActionScript3 = 1443 ms
DisplayList Rendering = 25 ms
Other = 131 ms
----- Original Message -----
From: "Maurice Amsellem" <ma...@systar.com>
To: users@flex.apache.org
Sent: Wednesday, October 23, 2013 5:21:45 PM
Subject: RE: any techniques to spread drawing of screen over several frames?
Hi,
In Scout, you can the breakdown of rendering vs actionscript for that particular 2sec frame.
What are the values ?
Maurice
-----Message d'origine-----
De : modjklist@comcast.net [mailto:modjklist@comcast.net]
Envoyé : jeudi 24 octobre 2013 02:12
À : users@flex.apache.org
Objet : Re: any techniques to spread drawing of screen over several frames?
That's a good suggestion Mark. I tried turning various components invisible, which didn't have any impact really. But it sounds like I should have used excludeFrom or includeIn instead. I can try again.
----- Original Message -----
From: "Mark Fuqua" <ma...@availdata.com>
To: users@flex.apache.org
Sent: Wednesday, October 23, 2013 4:57:17 PM
Subject: RE: any techniques to spread drawing of screen over several frames?
I am pretty clueless and don't want to imply anything different, but could you just comment out a bunch of components, then some others, narrowing it down...keep running the test until you see a spike?
Mark
-----Original Message-----
From: modjklist@comcast.net [mailto:modjklist@comcast.net]
Sent: Wednesday, October 23, 2013 7:27 PM
To: users@flex.apache.org
Subject: Re: any techniques to spread drawing of screen over several frames?
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net"
>>>><mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
RE: any techniques to spread drawing of screen over several frames?
Posted by Maurice Amsellem <ma...@systar.com>.
Hi,
In Scout, you can the breakdown of rendering vs actionscript for that particular 2sec frame.
What are the values ?
Maurice
-----Message d'origine-----
De : modjklist@comcast.net [mailto:modjklist@comcast.net]
Envoyé : jeudi 24 octobre 2013 02:12
À : users@flex.apache.org
Objet : Re: any techniques to spread drawing of screen over several frames?
That's a good suggestion Mark. I tried turning various components invisible, which didn't have any impact really. But it sounds like I should have used excludeFrom or includeIn instead. I can try again.
----- Original Message -----
From: "Mark Fuqua" <ma...@availdata.com>
To: users@flex.apache.org
Sent: Wednesday, October 23, 2013 4:57:17 PM
Subject: RE: any techniques to spread drawing of screen over several frames?
I am pretty clueless and don't want to imply anything different, but could you just comment out a bunch of components, then some others, narrowing it down...keep running the test until you see a spike?
Mark
-----Original Message-----
From: modjklist@comcast.net [mailto:modjklist@comcast.net]
Sent: Wednesday, October 23, 2013 7:27 PM
To: users@flex.apache.org
Subject: Re: any techniques to spread drawing of screen over several frames?
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net"
>>>><mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
That's a good suggestion Mark. I tried turning various components invisible, which didn't have any impact really. But it sounds like I should have used excludeFrom or includeIn instead. I can try again.
----- Original Message -----
From: "Mark Fuqua" <ma...@availdata.com>
To: users@flex.apache.org
Sent: Wednesday, October 23, 2013 4:57:17 PM
Subject: RE: any techniques to spread drawing of screen over several frames?
I am pretty clueless and don't want to imply anything different, but could you just comment out a bunch of components, then some others, narrowing it down...keep running the test until you see a spike?
Mark
-----Original Message-----
From: modjklist@comcast.net [mailto:modjklist@comcast.net]
Sent: Wednesday, October 23, 2013 7:27 PM
To: users@flex.apache.org
Subject: Re: any techniques to spread drawing of screen over several frames?
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
RE: any techniques to spread drawing of screen over several frames?
Posted by Mark Fuqua <ma...@availdata.com>.
I am pretty clueless and don't want to imply anything different, but could you just comment out a bunch of components, then some others, narrowing it down...keep running the test until you see a spike?
Mark
-----Original Message-----
From: modjklist@comcast.net [mailto:modjklist@comcast.net]
Sent: Wednesday, October 23, 2013 7:27 PM
To: users@flex.apache.org
Subject: Re: any techniques to spread drawing of screen over several frames?
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
Listen to the LayoutManager. I think the code is
LayoutManager.getInstance().addEventListener("updateComplete",...)
On 10/23/13 5:09 PM, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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" <ah...@adobe.com>
>>>>>To: users@flex.apache.org
>>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>>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" <ah...@adobe.com>
>>>>>>To: users@flex.apache.org
>>>>>>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, "modjklist@comcast.net"
>>>>>><mo...@comcast.net>
>>>>>>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?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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" <ah...@adobe.com>
>>>>>To: users@flex.apache.org
>>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>>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?
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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" <ah...@adobe.com>
>>>>>To: users@flex.apache.org
>>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>>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?
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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" <ah...@adobe.com>
>>>>To: users@flex.apache.org
>>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>>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?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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?
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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" <ah...@adobe.com>
>>>To: users@flex.apache.org
>>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>>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?
>>>
>>>
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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?
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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" <ah...@adobe.com>
>>To: users@flex.apache.org
>>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, "modjklist@comcast.net" <mo...@comcast.net>
>>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?
>>
>>
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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?
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net> 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" <ah...@adobe.com>
>To: users@flex.apache.org
>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, "modjklist@comcast.net" <mo...@comcast.net>
>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?
>
>
Re: any techniques to spread drawing of screen over several frames?
Posted by mo...@comcast.net.
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" <ah...@adobe.com>
To: users@flex.apache.org
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, "modjklist@comcast.net" <mo...@comcast.net>
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?
Re: any techniques to spread drawing of screen over several frames?
Posted by Alex Harui <ah...@adobe.com>.
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, "modjklist@comcast.net" <mo...@comcast.net>
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?