Re: [Frame Timing] Web platform tests

Hello all,

Thanks for the test. The test is very helpful to me!

Just a quick note about the tests running on Firefox with my current
implementation of the Frame Timing API. (with removal vendor prefix)

test_frame_on_frame_timing_buffer_full.html	PASS		2/2
test_frame_on_frame_timing_buffer_full_not_called.html	PASS	1/1
test_frame_timing_clear_frame_timings.html	PASS		4/4
test_frame_timing_composite.html	PASS		21/21
test_frame_timing_cross_origin_iframe.html	PASS		3/3
test_frame_timing_css_animation.html	PASS		5/5
test_frame_timing_iframe.html	FAIL		9/25
test_frame_timing_offpage_iframe.html	FAIL		5/7
test_frame_timing_render.html	FAIL		9/21
test_frame_timing_set_buffer_size.html	PASS		2/2

There might be some bugs in my implementation but most of failures are
caused by timing issue as Brian noted.


On 2015年06月16日 10:45, Brian Birtles wrote:
> 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] 
> [2] As introduced here:
> [3] As discussed here:

Hiroyuki Ikezoe <>

Received on Tuesday, 16 June 2015 13:38:50 UTC