[minutes] 20110622 Web Performance WG Teleconference #38

Meeting Summary:



1.      Discuss Unified Proposal

a.       WG agrees on inheritance model for Timing specs

The WG agreed with the last iteration of the unified proposal suggested in http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0075.html. Jatinder and Zhiheng will work on updating all existing Timing specs with the inheritance behavior described in the unifying proposal. As the Navigation Timing spec has defined the window.performance interface, it should also define the PerformanceEntry and PerformanceEntryList interfaces. Once this version has been updated, WG would like to send out broadly to get feedback.



b.       Impact to Navigation Timing PR

Updating Navigation Timing to include PerformanceEntry and PerformanceEntryList interfaces will not take it from PR to CR. However, it will call for a one month period of Last Call to gather feedback on the updated delta. The bar for changes to the existing portions of the spec will be higher, as we want to focus attention on the newly added delta. With these changes, we should also take Resource and User Timing into Last Call.



c.        Prototype tests for Timing specs

As the spec prototypes have been relatively simple, we haven't yet had prototype tests. Now that we are adding additional interfaces, we should update the test suite to include prototype tests, particularly for Navigation Timing. Action on Karen Anderson to add a new prototype test case.



2.      Discuss Battery Status specification feedback

Based on the description of the spec in the call, the WG is happy with the spec. From a Web Performance WG perspective, giving web developers more information on the system, like battery status, will only help developers create sites that are more power conscious. The one issue that was noted in the call was whether the initBatteryStatusEvent() was needed.



3.      Discuss requestAnimationFrame open issues

The WG reviewed the seven open issues on the requestAnimationFrame spec. A fine majority of the issues had relative agreement in the working group and just needed the changes to be made. Cameron has agreed to start making updates to the spec by next week.



We had the following action items from this meeting:

1.       Zhiheng Wang and Jatinder Mann: Update NT, RT, UT specs to include inheritance model.

2.       Karen Anderson: Submit new test cases that will test prototypes.

3.       Cameron McCormack: Update requestAnimationFrame spec next week.



Detailed Notes:



Web Perf Teleconference #38 6/22/2011



IRC log: http://www.w3.org/2011/06/22-webperf-irc


Meeting Minutes: http://www.w3.org/2011/06/22-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)
Jatinder Mann, Zhiheng Wang, Philippe Le Hegaret, James Simonsen, Nic Jansma, Karen Anderson


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)
Cameron McCormack, Jatinder Mann, Philippe Le Hegaret, Nic Jansma



Regrets

James Robinson, Christian Biesinger, Tony Gentilcore, Arvind Jain, Jason Weber, Kyle Simpson



Scribe

Jatinder Mann



Contents

Agenda
1.       Discuss Unified Proposal.
2.       Discuss Battery Status specification feedback.
3.       Discuss requestAnimationFrame open issues.
4.       Any other business.




--------------------------------------------------------------------------------
Discuss Unified Proposal.

Jatinder: As per last week's action items, we had sent out a proposal that combined inheritance with the current spec: http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0075.html.
... What are your thoughts?

James: I liked it a lot.

Zhiheng: It looks cool!
... Thoughts about Jatinder's suggestion about putting them into different namespace?

Jatinder: That was an initial suggestion to give structure. I feel that the current proposal gives us that structure.

James: I agree that the new proposal takes care of that.

Zhiheng: Ok.

Jatinder: We may want to go ahead and make changes to Navigation Timing to include the unified behavior and then solicit feedback from the mailing list.

James: Are there any other mailing list that have more traffic to give feedback?

phl: We can use Web Apps, but they may not give feedback here.

Jatinder: Is there any impact on Navigation Timing spec if we add the new interfaces?

phl: It will remain in PR, it would not necessarily go to CR, but it would be one month in LC.

Jatinder: If we go to LC, aren't we opening all areas of the spec to question, not just the delta?

phl: We can set the bar higher for existing portions of the spec and focus feedback on the deltas.
... We may also want to add prototype tests to the test suites now that the prototype is not as simple as before.

Karen: Agreed.

The WG agrees to update the Navigation Timing spec to add the current unified proposal sent last week and send that out for additional feedback. Jatinder will send some text to Zhiheng to consider adding to the spec.
Discuss Battery Status specification feedback.

Jatinder: Let's discuss feedback on the Battery Status spec: http://dev.w3.org/2009/dap/system-info/battery-status.html
... Seems like a very simple API set: "isPlugged" gives you whether the device is on battery, "level" gives you a scaled representation from 0 - 100 of your battery level, and batterystatus gets fired when the battery status changes (level varies by 1% or isPlugged changes).
... Not sure of the value of initBatteryStatusEvent(). Similar idea to the initEVent() in DOM Level 2 and 3 specs, http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-initEvent.

The WG is relatively happy with the spec based on description on the call.
Discuss requestAnimationFrame open issues.

Jatinder: Let's go through each open issue on requestAnimationFrame and get an update from the editors - http://www.w3.org/2010/webperf/track/issues

<heycam> http://www.w3.org/2010/webperf/track/products/5

ISSUE-1: Scheduling processing model needs to be more tightly defined 2011-05-18

<trackbot> ISSUE-1 Scheduling processing model needs to be more tightly defined notes added

Cameron: Needs to be tightened up. Otherwise no real issues.

Jatinder: We don't have any issues here.

Next: Callback time parameter needs definition 2011-05-18

Nic: Are we defining the exact time that the frame was going to be drawn?

Cameron: Yes.

Nic: In the case that the callback takes more than one refresh rate, we may want to rely on the previous frame instead the next frame.

Cameron: Since they are clock times, it shouldn't matter. Maybe we should use the clock tick time.

Next: Animation frame times should be monotonically increasing 2011-05-18

<plh> http://www.w3.org/TR/navigation-timing/#mono-clock

Nic: If I remember correctly on the list, as long as the timestamp parameter is also monotonically increasing, this would make sense.

Jatinder: This issue should also consider including window.animationStartTime.

Cameron: Yes.

Next: We perhaps should support an element parameter to requestAnimationFrame()

Jatinder: We should consider making this optional.

Nic: It would be hard to do feature detection for an optional argument

Jatinder: This argument defines element visibility. Web developers should a graceful fallback to visible.

Next: Expected callback rates should be documented 2011-05-18

Cameron: We had agreed that the expected callback rate should match the display refresh rate. We would probably not want to make this a must statement, but rather should.

Jatinder: Agree.

Next: Spec needs to clarify expected behavior for duplicate calls of the same callback 2011-05-25

Jatinder: I believe everyone on the list agreed to duplicate callbacks.

Cameron: Yes.

Next: FrameRequestCallback interface should be designated as Callback=FunctionOnly

Cameron: Whatever WebIDL defines, requestAnimationFrame should follow, since this issue isn't local to just requestAnimationFrame.

Jatinder: Agreed.
... Considering there are two implementations for this spec, and we are all relatively in agreement with the design, I expect this spec to move quickly. When do we expect to have all these issues completed by?

Cameron: I been busy of late. Will discuss with James further. Hopefully, I will start making changes next week.

<heycam> http://www.w3.org/mid/4DF60DEF.7060005@labri.fr

<heycam> https://mail.mozilla.org/pipermail/es-discuss/2011-March/013227.html

Cameron: David brought up this issue, which should be raised as an issue.