Re: [Frame Timing] Web platform tests

All the updated tests can be basically passed on Firefox with my current 
patch (except some tests I've commented in the pull request[1][2]). But 
css_animation test fails occasionally. The test expects no render event 
while css animation but Firefox does sometimes render. I can see the 
same behavior on Chrome. (The test fails on Chrome too.)

Another note about the test results on Chrome. clear_frame_timings fails 
on Chrome. The test waits for 100ms to get a render events, but 100ms is 
not sufficient on my local machine. I'm suspecting this test will fail 
on Android Firefox because of the same reason. This time out issue will 
be solved when the test is rewritten with PerformanceObserver though.

[1] 
https://github.com/ericwoodwork/web-platform-tests/commit/82b49e87534af0c1fca22801bbcbc0d9c8fe1b96#commitcomment-11694120
[2] 
https://github.com/ericwoodwork/web-platform-tests/commit/82b49e87534af0c1fca22801bbcbc0d9c8fe1b96#commitcomment-11738358

-- 
hiro

On 06/19/15 13:17, Michael Blain wrote:
> Eric reworked the tests to not rely on strict timing for render events.
> Please take a look and see if it works any better in your demo/test
> environment?
> Thanks!
> -Mike
>
> On Mon, Jun 15, 2015 at 7:04 PM, Hiroyuki Ikezoe
> <hiikezoe@mozilla-japan.org <mailto:hiikezoe@mozilla-japan.org>> wrote:
>
>     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
>     <mailto:hiikezoe@mozilla-japan.org>>
>
>

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

Received on Friday, 19 June 2015 08:50:13 UTC