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.

-- 
hiro

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] 
> 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
> 

-- 
Hiroyuki Ikezoe <hiikezoe@mozilla-japan.org>

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