On 8/30/12 7:49 PM, "jude" <flexcapaci...@gmail.com> wrote:
> On Thu, Aug 30, 2012 at 4:09 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> On 8/30/12 1:36 PM, "jude" <flexcapaci...@gmail.com> wrote:
>>> Remember when iOS 5 came out a year or so ago? The HTML5 performance in
>>> that browser was 2FPS. After that update it was 35-40FPS. A 2000%
>> increase.
>>> [1]
>> Yes, things get faster, but I would say that performance has been an issue
>> for Flex for its entire lifetime, and faster devices have not alleviated
>> the
>> problem. If Flex 1.0 had gone for a cleaner architecture, it isn't clear
>> it
>> would have been successful enough to end up here in Apache.
>>
>
> I've been trying to figure that out as well. Why is it that the same
> animation in Flex is not as smooth as the same animation in Flash (in my
> tests)? I thought maybe Flex was animating on pixel level while Flash is
> animating on a sub pixel level but in my research into the Animation
> classes it seems they *are* using Number (if I'm correct). There was a
> property on the Animate specifications that was effectively roundToInt /
> pixel but it seems to have been removed or renamed but could possibly still
> be in there. If somewhere along the line the value is getting converted to
> ints that might be causing it. Anyway, if you know where the bottle necks
> are I might be able to help (since I don't).
If you have a side-by-side test case, then we can analyze and figure out the
differences. AFAIK, if you use Flash to create the same display list, the
performance of animation will be the same. But generally, Flash folks have
fewer objects on the display list.
>
> Well, sortof. I know that with the transitions and effects classes that the
> first time through in some of my tests it took from 20 to 200 ms to
> initialize or create them (I had a lot of animations). That's the
> difference between the call to sequence.play and the startEffect event and
> the first child startEffect event (something like that). In subsequent
> calls the time between them was less than 1 ms. So if they're being
> deferred then that's what's causing the initial low frame rate. I would
> rather have the choice to have them created right away if it meant smoother
> animation.
At one point, I prototyped a new LayoutManager that gave lower priority to
things that were not on the display list. The idea was you could then start
pre-baking your next screen "in the background" so it would be ready to go.
Sure there would be situations where you could get surprised and not have
the right screen baked and you probably wouldn't want to bake everything,
but the idea was to make LayoutManager do a better job of not interfering
with the frame rate.
>
> Another issue is to find out if it's the creation, validation or render
> that's the issue. I don't know of any tools that report this for SDK
> classes.
The profiler will kind of tell you this today. The amount of time you spend
in LayoutManager.doPhasedInstantiation is the amount of time you spent in
validation, and the [render] entry is the amount of time spent rendering.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
