flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From modjkl...@comcast.net
Subject Re: any techniques to spread drawing of screen over several frames?
Date Wed, 23 Oct 2013 21:52:34 GMT
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 

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 
>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 
>Well, those numbers mean that a lot of work is going on, but it is hard 
>say if it is excessive without call counts. Let's see what the FB 
>profiler has to say. 
>On 10/23/13 2:08 PM, "modjklist@comcast.net" <modjklist@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 
>>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 
>>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 
>>----- 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 
>>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 
>>frame It should be a small number like 3 or 4. If it is higher, then 
>>there is extra invalidation going on that, if you can eliminate it (and 
>>you can't always) could drastically affect the execution time of that 
>>A new navigator view should switch the LayoutManager to phased 
>>instantiation mode and spread the validation across multiple frames so 
>>mouse cursor doesn't stick. 
>>Also make sure you are not using creationPolicy="all" in any navigators. 
>>That is always a performance killer. 
>>Only instantiate components that are visible. Postpone instantiation of 
>>components that aren't. 
>>You can use various tricks like changing states to incrementally add 
>>components to the screen. 
>>You can use modules to load whole sections of UI "later". 
>>On 10/23/13 12:03 PM, "modjklist@comcast.net" <modjklist@comcast.net> 
>>>One of the views in my app takes a few seconds to appear on the screen. 
>>>During this time the mouse icon appears frozen (recovering after the 
>>>screen is fully drawn). 
>>>Profiling with Scout, I can see the related frame, which, this one 
>>>takes a couple seconds to complete. I'm guessing this is due to a 
>>>complex view to layout and draw. 
>>>When I implement a stopwatch timer throughout the ActionScript code, 
>>>times spent within the functions are negligible. So I'm guessing most 
>>>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? 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message