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

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.



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