flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: any techniques to spread drawing of screen over several frames?
Date Thu, 24 Oct 2013 03:27:03 GMT
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" <modjklist@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" <maurice.amsellem@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" <mark@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" <aharui@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" <modjklist@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" <aharui@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" <modjklist@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" <aharui@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" <modjklist@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" <aharui@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" <modjklist@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" <aharui@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"
>>>>><modjklist@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?
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>
>
>
>
>
>


Mime
View raw message