Re: [Frame Timing] Web platform tests

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