Resubmitting r9970 again (again) - updating Animation to use the native requestAnimationFrame, which generally results in optimal performance versus using timer based animations. I did away with the soft permutation in this version.  Basing the impl on user agent leads to a smaller code footprint versus a soft perm because a soft perm includes all implementations, whereas we now only include the native and timer backup implementations in any permutation.

After seeing some of the demos at Google IO, I'm excited about the awesomeness and simplicity of requestAnimationFrame, even beyond the Animation class.  Animation carries the implicit restriction that it must execute over a fixed amount of time, so it can't be used for something like a game or unbounded animation. So, I've modified tbroyer's patch and added static methods Animation.requestAnimationFrame(Callback,Element)/cancelAnimationFrame().  These are alternatives to using a Timer or a Scheduler, and the Animation class makes use these static methods.

AnimationTest wasn't included in a test suite, so we aren't running it in our build, which is good, because its flaky as heck.  I created a StubAnimationSchedulerImpl that lets you manually trigger the AnimationCallback, specifying a mock timestamp. This allowed me convert the asynchronous tests in AnimationTest into synchronous tests, add more tests, and remove the flakiness.  I fixed some edge conditions revealed by the new tests.  Specifically, cancelling (or restarting) an animation within onStart/onComplete/onUpdate would usually result in a bad state.  Now, we increment a runId so we can detect that the current run has been canceled and gracefully move on. The tests are part of AnimationSuite, which will run in our build.

Author: tbroyer,jlabanca
Issue: 5639

Review at http://gwt-code-reviews.appspot.com/1446812

Review by: fabbott@google.com

git-svn-id: https://google-web-toolkit.googlecode.com/svn/trunk@10257 8db76d5a-ed1c-0410-87a9-c151d255dfc7
16 files changed