See also: IRC log
<trackbot> Date: 10 October 2012
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].
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/
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 th
... 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.
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> 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
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Default Present: +1.650.253.aaaa, +1.503.264.aabb, +1.650.214.aacc, [Microsoft], Plh Present: +1.650.253.aaaa +1.503.264.aabb +1.650.214.aacc [Microsoft] Plh Jatinder plh Arvind Tony Ganesh WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/10-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]