Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of aharui@adobe.com designates
 64.18.1.27 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Fri, 31 Aug 2012 20:23:30 -0700
Subject: Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on
 Falcon donation)
Thread-Topic: Cross-compiling Flex to HTML5/Javascript (Was : Update on
 Falcon donation)
Thread-Index: Ac2H2LnKgSj0W8ydQHu3IPzuaL6ZfQAGG63w
Message-ID: <CC66CDC2.458F3%aharui@adobe.com>
In-Reply-To: 
 <CANcBHEAhkoe3cXn9UwuXSercbPcmrAjMcYGbKtWtt6PUKCMY7w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


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 hav=
e
>> 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 interferin=
g
>> with the frame rate.
>>=20
>=20
> 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 b=
ut
> 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 explicitl=
y
> set) as well. If you start working on this let me know.
>=20
> I went back and ran some more tests and the FPS during animations is soli=
d
> (120fps). So there's something else going on. Maybe it's the graphics car=
d.
> 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.

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