- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 16 Jun 2015 10:45:35 +0900
- To: Michael Blain <mpb@chromium.org>, public-web-perf <public-web-perf@w3.org>
- CC: Hiroyuki Ikezoe <hiikezoe@mozilla-japan.org>
On 2015/06/16 6:55, Michael Blain wrote: > Hi all, > Here are a few Web Platform tests for the Frame TIming API. > > I understand that Mozilla, Chrome and IE have all pretty much decided to > gate Frame Timing on the Performance Observer spec, so some of the > details of the calls will change, but this is what we've been testing > Chrome's implementation against. > > Any feedback would be appreciated! Thanks for contributing these. Please bear in mind that we would like to use these tests on test machines which are often under considerable load and have limited resources. For example, to avoid intermittent failures, when writing animation tests we normally assume a worst-case scenario where frames might be as much as 100s apart. From glancing at these tests it seems we're assuming a 5ms difference between triggering a render and the time recorded on the render entry. Is that correct? If so it would be quite unsuitable for the kind of test environment we (and I suspect others) use. I'd suggest these tests should be written in such a way that they don't make any assumptions about timeliness but just test, for example, the order/existence of events, their relative times etc. On a further note, the description of startTime seems to have been (incorrectly?) reverted.[1] The previous text that spelled out that it corresponds to the time passed to rAF callbacks for that frame made much more sense.[2] I bring this up here because the test appears to be following the updated text but that seems undesirable.[3] Best regards, Brian [1] https://github.com/w3c/frame-timing/commit/cf7fcf4985fb5e7475e0fe4c2b82d4b795d8e73e [2] As introduced here: https://github.com/w3c/frame-timing/pull/10 [3] As discussed here: https://github.com/w3c/frame-timing/issues/9
Received on Tuesday, 16 June 2015 01:46:10 UTC