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

On Wed, Oct 10, 2012 at 12:46 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  *Meeting Summary:*****
>
>  ****
>
> **1.       ***High Resolution Time to Proposed Recommendation*****
>
> The working group has reviewed and approved moving the High Resolution
> Time test cases, test_cross_frame_start.html, basic.html,
> monotonic-clock.html, to the approved folder with minor changes.
> Considering we have two independent and interoperable implementations that
> pass all the test cases, IE10 and Firefox 15, the working group has agreed
> to moving this specification to proposed recommendation. The call with the
> director will be scheduled for next week. ** **
>
>  ****
>
> **2.       ***Web Worker Performance Scenarios
> *There had been some discussion on moving the performance.now() method
> and the entire performance property to web workers. As there will be some
> design issues to consider, and as we may be interesting in considering
> other web workers specific scenarios (e.g., performance of spawning a web
> worker) in our next charter update, instead of making one off changes now,
> the working group has decided to consider all web worker changes in our
> next charter update and in the V2 version of the specs.****
>
> ** **
>
> **3.       ***requestAnimationFrame Feedback*****
>
> From the last call period of requestAnimationFrame, we have a few
> remaining open items that need to be closed. Jatinder to start a mail list
> thread to close the remaining items.****
>
> ** **
>
> **-          **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.****
>
> ** **
>
> **-          **ISSUE-4: support an element parameter to
> requestAnimationFrame(), http://www.w3.org/2010/webperf/track/issues/4 ***
> *
>
> The working group agreed to close out this issue as no browser vendor that
> supports requestAnimationFrame supports this optional element. We may want
> to consider element visibility in our next charter update and may consider
> adding the optional parameter in the next version of this spec.****
>
> ** **
>
> **-          **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.

- James


>  **
>
> **4.       ***Test Cases Update*****
>
> The working group has decided that submitted tests cases may continue to
> test both prefixed and unprefixed APIs, whereas approved tests will only
> test unprefixed APIs. This approach balances testing what the spec
> specifies and helping implementors complete their testing during
> development. ****
>
> ** **
>
> The working group will review the page visibility test cases that
> Microsoft has submitted:
> http://w3c-test.org/webperf/tests/submission/Microsoft/PageVisibility/. **
> **
>
> ** **
>
> **5.       ***‘Status of this Document’ Section*****
>
> Steve suggested some improvements to the ‘Status of this Document’
> template section of the specs. Philippe has agreed to review the feedback
> and make changes were appropriate. ACTION-106 - Look into updating the
> 'Status of this Document' template for all Performance specs [on Philippe
> Le Hégaret - due 2012-10-17].****
>
> ** **
>
>  ****
>
> *Detailed Notes:*****
>
> * *****
>
> *Web Perf Teleconference #84 10/10/2012*****
>
> * *****
>
> *IRC log:* http://www.w3.org/2012/10/10-webperf-irc ****
>
>  ****
>
> *Meeting Minutes:* http://www.w3.org/2012/10/10-webperf-minutes.html ****
>
>  ****
>
> *Attendees*****
>
> Jatinder Mann, Philippe Le Hegaret, Tony Gentilcore, Arvind Jain, Ganesh,
> Jason Weber****
>
>  ****
>
> *Scribe *****
>
> Jatinder Mann****
>
>  ****
>
> *Contents*****
>
> *Agenda*****
>
> **1.       **Review ‘Status of this Document’ text template****
>
> **2.       **Review HRT and Page Visibility Test Cases****
>
> **3.       **Discuss Web Worker performance scenarios ****
>
> **4.       **Discuss remaining RequestAnimationFrame action items****
>
> **5.       **Discuss Navigation Timing feedback****
>
> **6.       **Discuss potential new performance ideas****
>
>
> --------------------------------------------------------------------------------
> ****
>
> *Review ‘Status of this Document’ text template*
>
> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0007.html****
>
> Action Philippe to look into updating the 'Status of this Document'
> template for all Performance specs****
>
> <*trackbot*> Created ACTION-106 - Look into updating the 'Status of this
> Document' template for all Performance specs [on Philippe Le Hégaret - due
> 2012-10-17].****
>
> *Review HRT and Page Visibility Test Cases*
>
> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0014.html****
>
> *Jatinder:* Per the mailing list comments, we agree to moving
> test_cross_frame_start.html and monotonic-clock.html to the approved. There
> is a minor tweak for basic.html.****
>
> *Philippe:* I want to keep a test to check that now() should be on
> performance.****
>
> *Jatinder:* You can add an additional test that checks if now() exists on
> performance.****
>
> *Philippe:* Okay.
> ... Should we remove prefixes in the approved tests?****
>
> *Jatinder:* The approved tests should have the prefixes removed, but for
> implementation ease, the submitted tests can have the prefixes.****
>
> *Philippe:* That works for me.****
>
> *Jatinder:* Page Visibility:
> http://w3c-test.org/webperf/tests/submission/Microsoft/PageVisibility/****
>
> *Moving to HRT to proposed recommendation.*
>
> *Jatinder:* Regarding bringing HRT to Web Workers, we have already
> discussed that instead of just bringing the performance.now() property to
> web workers, we are also interested in understanding what it'll mean to
> move the entire performance property, including the Timing interfaces, to
> web workers. Those changes will require additional thought and should be
> covered in V2 of the timing specs. In addition, there may be other web
> worker specific scenarios that we may be interested in including in our
> next charter update, like performance of spawning new worker threads. I
> recommend that instead of making a one-off change now to move
> performance.now() to web workers, we consider all the web worker changes we
> want to make in our next charter update and in V2 of the specs.
> *Philippe:* I agree.****
>
> *Tony:* I agree as well.****
>
> *Philippe:* Considering we have two implementations (IE and FF) that pass
> the test suite, I recommend we move this specification to Proposed
> Recommendation.
> ... Does the WG agree?****
>
> *Jatinder:* I agree.****
>
> *Tony:* I agree.****
>
> *Philippe:* Thanks. I will setup a call for PR for next week.****
>
> *RequestAnimationFrame*
>
> http://www.w3.org/2010/webperf/track/actions/31****
>
> <*plh*> action-31?****
>
> <*trackbot*> ACTION-31 -- Cameron McCormack to consider including
> window.animationStartTime and the requestAnimationFrame() callback
> timestamp as monotonically increasing clocks, in UTC format with
> millisecond resolution. -- due 2012-02-29 -- OPEN****
>
> <*trackbot*> http://www.w3.org/2010/webperf/track/actions/31****
>
> <*plh*> issue-4?****
>
> <*trackbot*> ISSUE-4 -- We perhaps should support an element parameter to
> requestAnimationFrame() -- raised****
>
> <*trackbot*> http://www.w3.org/2010/webperf/track/issues/4****
>
> http://www.w3.org/2010/webperf/track/issues/4****
>
> *Jatinder:* There are two parts to this request: define
> window.animationStartTime and update the rAF callback parameter to be
> DOMHighResTimeStamp. The second part has been updated in the latest
> editor's draft. We should close on whether we want animationStartTime or
> not. animationStartTime has the benefit of helping synchronize multiple
> animations.****
>
> <*plh*>
> http://www.useragentman.com/blog/2012/09/23/cross-browser-gpu-acceleration-and-requestanimationframe-in-depth/
> ****
>
> <*plh*> What’s requestAnimationFrame Doing When A Tab’s Not Visible?
> Depends On The Browser!****
>
> <*plh*> [[****
>
> <*plh*> Note****
>
> <*plh*> The expectation is that the user agent will run tasks from the
> animation task source at at a regular interval matching the display's
> refresh rate. Running tasks at a lower rate can result in animations not
> appearing smooth. Running tasks at a higher rate can cause extra
> computation to occur without a user-visible benefit.****
>
> <*plh*> ]]****
>
> *Tony:* Is animationStartTime supported in IE10?****
>
> *JatindeR:* Yes it is.****
>
> *Tony:* We should have Jamesr look at this.****
>
> http://www.w3.org/2010/webperf/track/issues/5****
>
> <*plh*>
> http://lists.w3.org/Archives/Public/public-web-perf/2011May/0018.html****
>
> *Jatinder:* Regarding issue 4, I recommend we do not support element
> parameter. No browser supports the implementation today. If we want to
> consider this, we can look at in V2.****
>
> <*plh*>
> http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/basic.html
> ****
>
> *Philippe:* I agree. Let's close the issue****
>
> Close issue 4****
>
> <*plh*> "Statements of interest will be the basis for the discussion at
> the Workshop. What performance issues have you faced? What use cases would
> you like to ensure that implementations support? If you have tests to
> illustrate an issue or use case, please share them as well."****
>
> *Philippe:* On the issue of requestAnimationFrame behavior when the page
> is not visible, seems like FF, Chrome and IE have different implementations.
> ****
>
> *Jatinder:* IE does not fire the callbacks when the page is not visible -
> which is actually the most power efficient option, as there is no benefit
> to fire callbacks for an animation that a user can't see. For time based
> animaitons, not firing the callbacks when page is not visible will not
> impact how the animation would look when the page is visible.
> ... I believe FF does an expontential backoff. I prefer if the spec is
> specific on the rate of callback. I'll follow up on the mailing list on
> this as well.****
>
> Close ISSUE-4****
>
> <*trackbot*> ISSUE-4 We perhaps should support an element parameter to
> requestAnimationFrame() closed****
>
> ** **
>