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). 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. 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.
