[minutes] 2012-03-28 Web Performance WG Teleconference #66

Meeting Summary:



1.    Navigation Timing

Considering WebIDL has moved to the next stage, the working group expects Navigation Timing to go to PR in mid-April.



2.    Resource Timing

With the latest editor's change to update the Resource Timing processing mode image, there are no remaining feedback items remaining for this spec. The working group has asked Philippe to take this spec to CR.



3.    User Timing

a. measure Method Exceptions

The working group decided to raise an INVALID_STATE_ERR exception when a startMark, endMark or both arguments have the same name as a PerformanceTiming attribute with a value of zero, indicating a same origin protection or the phase not occurring.



b. User Timing to CR

With these last changes to User Timing, the User Timing spec is ready to go to CR.



4.    Performance Timeline

There is no open Last Call feedback issues on this spec. The working group would like to move this spec to CR.



5.    High Resolution Time

a. Minimum Resolution

The working group has decided that the specification should have a "SHOULD" requirement to provide at least microsecond resolution.




Detailed Notes:



Web Perf Teleconference #66 3/28/2012



IRC log: http://www.w3.org/2012/03/28-webperf-irc


Meeting Minutes: http://www.w3.org/2012/03/28-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)

Jatinder Mann, Philippe Le Hegaret, Alois Reitbauer, James Simonsen


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)

Meeting cancelled.



Scribe

Jatinder Mann



Contents

Agenda

1.     Review feedback on all specifications

--------------------------------------------------------------------------------
User Timing

Jatinder: "Throws a SYNTAX_ERR exception if either startMark or endMark argument, or both, have the same name as a PerformanceTiming attribute with a DOMHighResTimeStamp time value of 0."n

<plh> http://www.w3.org/TR/domcore/#exception-domexception

Jatinder: This exception protects from comparing against a Navigation Timing attribute that has been zero'd out due to cross-origin restrictions. If we allow this operation to occur, folks may get misleading data. I am in favor of raising an exception here, however, this isn't exactly a syntax error; this may better be a INVALID_STATE_ERR.n

plh: Would we consider this a security_err?

Jatinder: "The operation is insecure" doesn't sound accurate.

<plh> INVALID_ACCESS_ERR

<plh> "The object does not support the operation or argument. "

Alois: I think invalid_access_err should be the one. Because it is something that isn't supported.

James: We can just throw this one out there and see how folks react.

Jatinder: "Throws a SYNTAX_ERR exception if the duration (the end mark DOMHighResTimeStamp time value minus the start mark DOMHighResTimeStamp time value) is negative."n

The reason behind including this exception may have been to protect from comparing against a Navigation Timing attribute that has not yet loaded. E.g., performance.measure('measure1', 'navigationStart', 'loadEventEnd'), where the load event has not yet fired.

Jatinder: However, the zero case above should cover the scenario where you are measuring against loadEventEnd but the load hasn't yet fired.
... I think there is some value in being able to return negative measures. If I can do performance.measure('myMeasure', 'mark1', 'mark2') and getting all measures returns [5.0], then performance.measure('mymarkInverse', 'mark2', 'mark1') should return [-5.0].n

James: I think the negative case should be fine.

Jatinder: Sigjborn had feedback on whether we should even use exceptions.

James: plh, do we know if exceptions are still commonly used?

plh: Yes, they appear to be.

James: Between exceptions and negative numbers, I think we should just use exceptions.
High Resolution Time

Jatinder: There was feedback on whether we should change the resolution. We can either create an attribute that describes the User Agent's minimum resolution or change the recommended resolution.nnnWe change the spec text to say "MUST" return microsecond resolution. If hardware doesn't support millisecond resolution, or if high precision clocks are not available, then MUST return millisecond resolution. Most developers will just assume microseconds.

We can either create an attribute that describes the User Agent's minimum resolution or change the recommended resolution.nnnWe change the spec text to say "MUST" return microsecond resolution. If hardware doesn't support millisecond resolution, or if high precision clocks are not available, then MUST return millisecond resolution. Most developers will just assume microseconds. Those that want to check can always

scribe: or we can add an attribute that describes the resolution.

Alois: I have had to do similar research on resolution of different systems, and I recommend that we shouldn't surface those complexities to the web platform. I recommend we don't add the attribute.

plh: We should add a "SHOULD" requirement in the spec and add a note that describes the scenario where sub-millisecond clock may not be available and what developers should do to determine that.

Jatinder: Okay, I will make those changes. Also, I think we should change the minimum resolution to microseconds.

James: Agreed.

Jatinder: Another piece of feedback was that performance.now() definition should make it clear that it does not remove the time of suspension when not fully active. Seems redudant to include that considering now defines the "current" time.

James: We may want to add a note in the spec to clarify the behavior. It doesn't have to be normative.

plh: You can also add an optional test case and it doesn't have to be required.

Jatinder: I will follow up on the mailing list.
Spec Status

plh: Considering WebIDL has moved to the next stage, we expect to bring Navigation Timing to PR in April.

Jatinder: With the latest Resource Timing change, we have no remaining open items on the spec.
... With the User Timing changes, we should be able to take this spec to LC. I will email you when I have made the final changes.