W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2012

Re: [requestAnimationFrame] Test Suite

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 29 Feb 2012 14:00:58 -0500
Message-ID: <4F4E75EA.9090807@mit.edu>
To: "Karen Anderson (IE)" <Karen.Anderson@microsoft.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
On 2/29/12 12:40 PM, Karen Anderson (IE) wrote:
> Thank you for bringing that to my attention.  I know we discussed it at some point but didn't realize it made it into any of the specs.  I see that http://www.w3.org/TR/animation-timing/#the-WindowAnimationTiming-interface shows cancelAnimationFrame, whereas http://www.w3.org/TR/2011/WD-animation-timing-20110602/#the-WindowAnimationTiming-interface shows cancelRequestAnimationFrame.

Yeah, TR is out of date as usual....

> From what I can tell, of the browsers that have implemented the cancel functionality, they have done so with cancelRequestAnimationFrame.

Gecko implements both, with prefixes, for what it's worth.  Our 
unprefixed implementation will only have cancelAnimationFrame.

> WRT the test against 60Hz, I think we can all agree that the base case need for this API is to fire callbacks at the same rate as the user's vsync

No, the base case is to allow the UA to fire them at whatever rate will 
lead to the smoothest real-time animation, I would think.

If the UA detects that each callback takes > 16ms, for example, I think 
it's perfectly reasonable for the UA to back off on the firing rate to 
preserve the smoothness of the animation.

But all that is beside the point.  We can't test things the spec doesn't 
actually require, and the spec does not require the behavior this test 
is testing.

> What I pushed was not a definitive list of everything that can be tested.  Certainly more tests around the processing model could be beneficial.  However, these are conformance tests.  We want to be interoperable, but testing what isn't conformance does not belong in a W3C test suite.

Yes, hence my objection to the "frame rate" test....

> 5.For every context in contexts, in any order, perform the following steps:

Ah, ok.  That's a change from what we last discussed on the list, I 
think.  Given that, testing order across documents is not called for, 
agreed.  Thanks for pointing that out!

We should still have tests for order within a browsing context and for 
cancelation behavior.  It doesn't have to be you that does this, 
obviously, but I think it should happen before the test suite is called 
finished.

If I didn't say it before, thank you for working on these tests!

-Boris
Received on Wednesday, 29 February 2012 19:01:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 February 2012 19:01:34 GMT