W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2012

Re: [minutes] 2012-10-10 Web Performance WG Teleconference #84

From: James Robinson <jamesr@google.com>
Date: Thu, 11 Oct 2012 12:45:38 -0700
Message-ID: <CAD73mdL1=9Eu89JS1J5N8YdnkgAQkGbZGsWDz5Ri7z3pfrpBww@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
On Thu, Oct 11, 2012 at 12:39 PM, Jatinder Mann <jmann@microsoft.com> wrote:

> On Thu, Oct 11, 2012 at 11:27 PM, James Simonsen wrote:
> >> On Wed, Oct 10, 2012 at 12:51 PM, Jatinder Mann wrote:
> >> -          ISSUE-5: Expected callback rates should be documented,
> http://www.w3.org/2010/webperf/track/issues/5
> >> There had been feedback to the working group that browsers have
> different behaviors on the expected callback rate
> >> when the page is not visible; Firefox and Chrome throttle callbacks, IE
> does not issue callbacks. The spec needs to be
> >> clear on whether we want to have a specific definition on the expected
> behavior or specifically call out that this is
> >> implementation specific behavior.
> >
> > The processing model requires that callbacks not fire when the page is
> not visible.  See the first sentence of
> > "
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#processingmodel".
> > Chrome does not issue callbacks at all when a page is not visible, as
> the spec requires.  I don't think we should make
> > this implementation specific.
> I'm glad the spec is very precise on this point and that it defines the
> more efficient option. There was some confusion in the conf call yesterday
> where some folks thought the spec wasn't clear. Thanks for clearing this up.
> > On Wed, Oct 10, 2012 at 12:51 PM, Jatinder Mann wrote:
> > -          ACTION-31: Consider including a window.animationStartTime and
> use High Resolution Time for the rAF callback
> > parameter, http://www.w3.org/2010/webperf/track/actions/31
> > The second request in this action, updating the rAF callback parameter
> to use DOMHighResTimeStamp instead of
> > DOMTimeStamp, has already been completed in the latest editor's draft.
> The issue to include
> > window.animationStartTime in the specification will be discussed on the
> mailing list.
> In order to help synchronize multiple animations, the
> window.animationStartTime should return a DOMHighResTimeStamp time value at
> which animations started now should be considered to have started, which
> should be the same as the rAF callback parameter time value at that given
> time. This would help synchronize script animations with CSS animations,
> CSS transitions, and audio. The alternative would be to storing the
> callback parameter value in a global on every rAF callback.

> As window.animationStartTime was included in an earlier version of the
> spec and we expected this to make the spec, IE10 implements
> window.animationStartTime. Firefox also implements
> window.mozAnimationStartTime.

The animationStartTime has never been part of a W3C specification.  For CSS
animations, I do not believe this is implementable in WebKit.

- James

> I would like to see this added to the spec.
> I believe those were the only remaining issues on this spec.
> Thanks,
> Jatinder
Received on Thursday, 11 October 2012 19:46:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 11 October 2012 19:46:10 GMT