[gwt-contrib] Re: Adds {moz,webkit}RequestAnimationFrame support to animations. (issue1355805)

[t . broyer]

I stumbled upon this article by Paul Irish
<http://paulirish.com/2011/requestanimationframe-for-smart-animating/> a
few hours after sending this patch. There he says that Chrome 10 (beta)
doesn't pass the 'time' argument to the callback, so the
AnimationImplWebkit should probably test that and fallback to
Duration.currentTimeMillis(). I only tested in Chrome 11 at the time, so
I didn't notice it. I haven't had time to work on that yet, but I'll
make sure to test in Chrome 9 (stable) and 10 (beta) in the next patch.


http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/Animation.gwt.xml
File user/src/com/google/gwt/animation/Animation.gwt.xml (right):

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/Animation.gwt.xml#newcode25
user/src/com/google/gwt/animation/Animation.gwt.xml:25:
<property-provider name="animationTimingSupport"><![CDATA[
On 2011/03/03 19:26:22, jlabanca wrote:

This property provider is going to add 4 additional permutations:
gecko1_8:moz
gecko1_8:webkit // Compiler doesn't know this is invalid
safari:webkit
safari:moz // Compiler doesn't know this is invalid

I was hoping soft permutations would mitigate this (the wiki says: "It
is possible to collapse all properties to decrease the amount of time
spend compiling a module for testing purposes by adding the following:
<collapse-all-properties />" which I understood as "soft permutations
have a low overhead").

In my understanding, there would also have been the drawback of
compiling all AnimationImpl* into the gecko1_8 and webkit permutations,
but with the advantage of clean separation in the code (and possibility
to compile out some implementations in controlled environments where you
know the one impl that would fit; e.g. Firefox or Chrome extension)

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/Animation.gwt.xml#newcode48
user/src/com/google/gwt/animation/Animation.gwt.xml:48:
<when-property-is name="animationTimingSupport" value="moz" />
On 2011/03/03 19:26:22, jlabanca wrote:

Replace with:
<when-property-is name="user.agent" value="gecko1_8" />

Assuming I'm right above, maybe I should rather *add* that line?

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/client/AnimationImplMozAnimTiming.java
File
user/src/com/google/gwt/animation/client/AnimationImplMozAnimTiming.java
(right):

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/client/AnimationImplMozAnimTiming.java#newcode45
user/src/com/google/gwt/animation/client/AnimationImplMozAnimTiming.java:45:
if (!complete) {
On 2011/03/03 19:26:22, jlabanca wrote:

If you check !cancelled here, it could result in a bad state if the

Animation is

restarted synchronously.

What would you propose?

Would it also be an issue if 'cancelled' is checked before update() is
called (which should have been the case)

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/client/AnimationImplTimer.java
File user/src/com/google/gwt/animation/client/AnimationImplTimer.java
(right):

http://gwt-code-reviews.appspot.com/1355805/diff/3003/user/src/com/google/gwt/animation/client/AnimationImplTimer.java#newcode83
user/src/com/google/gwt/animation/client/AnimationImplTimer.java:83:
Scheduler.get().scheduleFixedDelay(animationCommand,
DEFAULT_FRAME_DELAY);
On 2011/03/03 19:26:22, jlabanca wrote:

If the animation runs slowly, we may end up animating with only 1ms

intervals in

between, which would make the UI unresponsive.  Can you use a

ScheduledCommand

instead of a RepeatingCommand, and reschedule manually with a delay?

This is what scheduleFixedDelay does (contrary to scheduleFixedPeriod):
http://google-web-toolkit.googlecode.com/svn/javadoc/2.2/com/google/gwt/core/client/Scheduler.html#scheduleFixedDelay(com.google.gwt.core.client.Scheduler.RepeatingCommand,
int)

You were probably thinking about the old, deprecated
DeferredCommand/IncrementalCommand.

Also, note that in the current implementation, this animationCommand

will never

stop executing in the background.

Er, wouldn't it stop when all animations complete? (animations would
then be empty and the animationCommand would then return false, which
would terminate the "loop")

http://gwt-code-reviews.appspot.com/1355805/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors