On Fri, Aug 31, 2012 at 12:09 AM, Alex Harui <aha...@adobe.com> wrote:
> > > > 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. > Do you remember how much difference it made? I think in most cases that would be alleviate a lot of the issues. Also, not sure if it's possible but maybe it could determine if an item is outside of the visible application rectangle and set lower priority on those items (esp if size is explicitly set) as well. If you start working on this let me know. I went back and ran some more tests and the FPS during animations is solid (120fps). So there's something else going on. Maybe it's the graphics card. I'm not sure how to describe what I'm seeing but it reminds me of when I was writing a drag manager back in the day (AS2) and you dragged a sprite across the stage. It didn't look great but it wasn't clear what was different than normal (and the FPS were still reporting the same numbers). Then I used event.updateAfterEvent() on each mouse move event and it was the difference was astounding. What was going on there and could the same thing be happening here? > > > 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. > At some point I'm going to write some infrastructure that you can run your components and effects through to find this out... Jude
