[minutes] 20110720 Web Performance WG Teleconference #42

Meeting Summary:



1.      Discussed feedback on the unifying updates to Navigation, Resource and User Timing.

a.       Create a new Performance Timeline spec

The WG agreed to remove all PerformanceEntry and PerformanceEntryList interface changes from Navigation Timing into a separate spec called Performance Timeline. This way Navigation Timing will be not have changed from its Candidate Recommendation version, http://www.w3.org/TR/navigation-timing/. Jatinder has taken an action to make this update.



b.       Performance Timeline and User Timing specs to be published as First Public Working Drafts next week

The WG has agreed to publish Performance Timeline and User Timing specs as FPWD next week after they have been updated.



c.        Navigation Timing to Recommended.

With the decision to remove PerformanceEntry and PerformanceEntryList interfaces from Navigation Timing, Navigation Timing spec will not have changed since it was in Candidate Recommendation. Considering the spec has two implementations and it now has a completed test suite, there is no remaining work left to take the spec to Recommended from the working group. Once the WebIDL spec has matured a bit more, we can consider taking this spec to Recommended (an exception will be granted for the HTML5 spec).



d.       Update User Timing IDL

Per changes to WebIDL, the User Timing IDL will be updated to Partial instead of Supplemental. Jatinder has taken an action item to make this change.



2.      Page Visibility will enter Last Call

Page Visibility will be in Last Call from July 21st to August 18th.



3.      Discuss requestAnimationFrame open issues

a.       The following open issues of the requestAnimationFrame spec remain:


1.       ISSUE-1: Scheduling processing model needs to be more tightly defined

James will be working on updating the spec to define the processing model in terms of an HTML5 task queue, so that animation frame callback scheduling participates in the browser event loop in a well defined manner.



2.       ISSUE-2: Callback time parameter needs definition

James will be working on updating the spec to be more clear that callbacks should match the refresh rate of the display.


3.       ISSUE-3: Animation frame times should be monotonically increasing

The spec needs a section to clarify that the animation frame times should be monotonically increasing, similar to what was stated in the Timing specs: http://www.w3.org/TR/2011/WD-resource-timing-20110524/#monotonic-clock. The spec should also include window.animationStartTime as a standardized way to get the start time for all animations in a given refresh interval, allowing them to remain in sync with one another.


4.       ISSUE-4: We perhaps should support an element parameter to requestAnimationFrame()

James will work on defining an optional element parameter to this API.


5.       ISSUE-5: Expected callback rates should be documented
There were a few callback throttling algorithms discussed for the case where the page is no longer visible, including no callbacks, exponential backoffs and a throttled callback. The WG agrees that this portion of the spec should be normative, rather than optional, to ensure most interoperability and least compatibility issues. Both Google and Microsoft implementations use the no callbacks algorithm, and they have not seen any issues so far. Cameron will follow up to see if Mozilla also agrees with this approach.


We had the following action items from this meeting:

1.       Cameron McCormack and James Robinson: Resolve requestAnimationFrame spec open issues.

2.       Jatinder Mann: ACTION-41 - Update User Timing and Page Visibility specs to use Partial in the IDL.

3.       Jatinder Mann: ACTION-42 - Remove PerformanceEntry and PerformanceEntryList and associated methods from Navigation Timing into a new Performance Timeline spec.

4.       Jatinder Mann: ACTION-44 - Add reference to WebIDL in the Page Visibility spec.

5.       Karen Anderson: ACTION-43 - Add Page Visibility test cases.



Detailed Notes:



Web Perf Teleconference #42 7/20/2011



IRC log: http://www.w3.org/2011/07/20-webperf-irc


Meeting Minutes: http://www.w3.org/2011/07/20-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)
Tony Gentilcore, James Simenson, Jatinder Mann, Philippe Le Hegaret, Nic Jansma, Zhiheng Wang, Christian Biesinger


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



Scribe

Jatinder Mann



Contents

Agenda

1.       Discuss feedback on the unifying updates to Navigation, Resource and User Timing.

2.       Discuss progress on requestAnimationFrame open items.

3.       Discuss feedback on the setImmediate specification.

4.       Any other business.




--------------------------------------------------------------------------------
Discuss feedback on the unifying updates to Navigation, Resource and User Timing.
Jatinder: Should we separate PerformanceEntry and PerformanceEntryList interfaces from the Navigation Timing in order to avoid taking Navigation Timing to last call? Should we add PerformanceEntry and PerformanceEntryList to its own spec or have it live in Resource Timing?
... Is one of the concerns that by taking the definitions out of Navigation Timing, we can avoid taking Navigation Timing back to last call?
Zhiheng: That is one of the concerns, but the main one is that the Timing attribute will not inherit PerformanceTiming.
Philippe: By putting PerformanceEntry into it's seperate spec, it will take at least three months before it can get to recommended. That means that Navigation Timing will not be able to move forward for at least three months.
Jatinder: Now that Navigation Timing has a complete test suite and two implementations, what remains to do for Navigation Timing to get to Recommended.
Philippe: Navigation Timing will depend on HTML5 and WebIDL specs. For HTML5, we can take an exception, but we will still need to wait for WebIDL to mature before we can take Navigation Timing to Recommended.
... We should seperate the PerformanceEntry and PerformanceEntryList into a new spec.
Jatinder: Why don't we call the new spec Performance Timeline, as that is what we refer to it currently.
James: I like the name.
Philippe: Remove supplemental from User Timing and use Partial.
Action Jatinder to update User Timing and Page Visibility specs to use Partial in the IDL.
<trackbot> Created ACTION-41 - Update User Timing and Page Visibility specs to use Partial in the IDL. [on Jatinder Mann - due 2011-07-27].
Action Jatinder to remove PerformanceEntry and PerformanceEntryList and associated methods from Navigation Timing into a new Performance Timeline spec.
<trackbot> Created ACTION-42 - Remove PerformanceEntry and PerformanceEntryList and associated methods from Navigation Timing into a new Performance Timeline spec. [on Jatinder Mann - due 2011-07-27].
Jatinder: Once Performance Timeline spec has been published, we can take both Performance Timeline and User Timing to first public working draft next week 7/27.
... Per WG decision, Page Visibility spec will be in Last Call from July 21st to August 18th.
Discuss progress on requestAnimationFrame open items.
Action Jatinder to add reference to WebIDL in the Page Visibility spec.
<trackbot> Created ACTION-44 - Add reference to WebIDL in the Page Visibility spec. [on Jatinder Mann - due 2011-07-27].
Cameron: I don't have any updates this week. James said on the mailing list that he will have some updates.
Philippe: We now have a new testing framework, I will go ahead and move the test suites to this framework. There may be bugs that I may open based on this move.
Jatinder: Considering James and Jason aren't on the call today, we can hold on the setImmediate discussion today.
Philippe: Cameron, how is the WebIDL Last Call coming?
Cameron: I'm working on spec bugs currently.
Philippe: Is it your sentiment that WebIDL spec will go to another Last Call?
Cameron: It may seem like a second last call is necessary.