incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
Date Sat, 01 Sep 2012 03:23:30 GMT



On 8/31/12 5:27 PM, "jude" <flexcapacitor@gmail.com> wrote:


>> 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?
No, I don't have any good numbers.  It would depend on how much stuff is
being created and validated.
> 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?
Mouse and Timer events do not automatically force a redraw of the screen at
the end of all code responding to the event.  When dragging, mouse events
can be occurring at a rate much higher than the frame rate, especially when
the frame rate is 24fps or so.

It is possible that in timer-driven animations, nobody is calling
updateAfterEvent and the timer is firing faster than the regular frame rate.

I think in mobile apps the player is currently throttling timers to the
frame rate.

I've wanted to play with blends and velocity to see if it can smooth out
animations at lower frame rates, but that is not very high on my list.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message