[minutes] 20110223 Web Performance WG

Web Performance Working Group
23 Feb 2011

See also: IRC log<http://www.w3.org/2011/02/23-webperf-irc>

Minutes
http://www.w3.org/2011/02/23-webperf-minutes.html
Attendees
Present
[Microsoft], Plh, +1.650.214.aaaa, +1.650.253.aabb, Shepazu, +1.650.214.aacc, +1.650.704.aadd, +1.650.704.aaee, Sigborn, TonyG, ArvindJain, JasonWeber, Zhiheng, plh, NicJansma, AndersonQuach, DougSchepers, JatinderMann, WalterVonKoch, JamesSimonsen
Regrets
Chair
JasonWeber; ArvindJain
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/02/23-webperf-minutes.html#agenda>
1.     New API: Visibility API<http://www.w3.org/2011/02/23-webperf-minutes.html#item01>
2.     New API: Efficient CPU usage: Yield and Continue, RequestAnimationFrame<http://www.w3.org/2011/02/23-webperf-minutes.html#item02>
3.     Conformance tests, Navigation Timing<http://www.w3.org/2011/02/23-webperf-minutes.html#item03>
4.     Candidate Recommendation for Navigation Timing<http://www.w3.org/2011/02/23-webperf-minutes.html#item04>
5.     User Timing<http://www.w3.org/2011/02/23-webperf-minutes.html#UserTiming>

  *   Summary of Action Items<http://www.w3.org/2011/02/23-webperf-minutes.html#ActionSummary>
Re-chartering Web Performance

i.              Jason Weber will send out a draft of a paragraph describing the scope of the work for each of the topics be chartered into the Web Performance working group, this includes: VisibilityAPI, Yield and Continue and requestAnimationFrame.

ii.             Arvind Jain will solicit feedback from the WGs for additional asks / work items to be chartered into the Web Perf WG.

Web Timings

iii.            Approved are the following tests:

http://w3c-test.org/webperf/tests/submission/Google/NavigationTiming/test_navigate_within_document.htm

*         The window.performance.timing property list will be factored out and incoroprated into the webperftestharness.js

http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_reload.htm

http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_client_redirect.htm

*         Resources will be factored out and the test directory will only contain the starting point for tests.

iv.            unloadEventStart and unloadEventEnd to remain as spec'd and be zeroed out in non-same origin redirect chains.

v.             Zhiheng will provide an updated Navigation Timing spec as we move to CR with a period of 3/16 to allow for time to get Navigation Timing conformance tests completed.

vi.            Anderson will update the User Timing spec to reflect the most recent conversations around measures and the return signature of getMarks.

vii.           The Web Perf WG will work towards 3/31 to get to a first draft of the User Timing and Resource timing spec.

________________________________
New API: Visibility API

ArvindJain: http://lists.w3.org/Archives/Public/public-web-perf/2011Feb/0023.html

JasonWeber: The idea is to enable efficient use of the tabs based on the visibility, as most all browsers are tab enabled. The idea here is to enable efficient CPU usage, especially for visual updates that are not seen by the end-user while consuming browser resources.

ArvindJain: Some work has started, however it's very early in Chrome.

TonyG: I've seen a demo that works.

ArvindJain: We've been prototyping having two states for the document, visible or not.

JasonWeber: That's a good starting point.

ArvindJain: We've been exploring alternate means to explore visibility or not.

JasonWeber: That's the first of the new APIs in the Web Perf Group to work together for website visibility.

plh: What I'm hearing, is that we want to add this topic in the charter. I'm going to make minimal charter changes to move this quickly. It would help to get 1-2 sentence of the scope of the topics we want to work on.

JasonWeber: This is an API that can be designed quickly and take the time to understand the compatibility impact to the web.

plh: We set the charter review, for 4 weeks, and allow 45 days to recommit to the patent policy. We will need the first working draft. A month or so from now at the earliest.

JasonWeber: We can start a working draft before the charter is set.

plh: Correct.

JasonWeber: I'll take point to send a paragraph of the work and send it to you folks in preparation for the re-charter within two weeks.

plh: Get this to me before Tuesday.

JasonWeber: The second area, was efficient painting, events related to drawing. We think there may be two more specs to be valuable to the WG to author.
... First, API is, setImmediate. One of the patterns we are starting to see. A website wants to do setTimeout(..,0); to prevent the long running script dialog. These APIs are overloaded for animation and yielding scenarios. This can improve top sites.
... Ties back to timer resolution relates to different user agents and small setTimeouts. It's a complex topic.

DougSchepers: I agree in principle separating the use cases and API will lead to a mature platform. And we'll get better performance when using these APIs.

TonyG: I have a question on that, how does this relate to requestAnimation proposal.

JasonWeber: This yield API is not really for animation, this is for when there's a large amount of JScript. You don't know what browser or machine you're working on and developers are forced to do a lot of setTimeout(..,0); to avoid long running script dialogs.
... In modern browsers, you end up with lots of little spikes of CPU activities, this is easier when seeing CPU charts and patterns.

TonyG: setTimeout(...,0); in general would break the web.

DougSchepers: Developers aren't really looking to have a timeout of zero.

TonyG: Two use cases, yield to the browser and another is to perform efficient animation. Is that a reasonable summary.

JasonWeber: Yes.

Sigborn: while(true) { //do something }; shouldn't the browser be responsible to stay responsive?

JasonWeber: Until that JavaScript yields, updates to the DOM and visual updates cannot be done. And the second was in IE6, the script dialog there's a long running script, do you want to continue to run.

plh: You're advocating new APIs for functionality that exists with current APIs. I'm not sure how this will help current browsers.

JasonWeber: Where this help is really in breadth of devices and low-end devices where CPU efficiency is important.
New API: Efficient CPU usage: Yield and Continue, RequestAnimationFrame

move to agenda 2

plh: This is not something Web workers will help with?

JasonWeber: No, I'll put together some CPU charts and code snippets to make it easier to see the problem.
... From a performance perspective, this is what we are worried about, this may save up to 10ms on page loads, forward looking this will impact web-apps. We feel like the Perf WG to standardize this API, as this is done for performance.

DougSchepers: Having it in the charter, and looking at it, is not a forcing function to drive this through to completion.
... I ran into setTimeout(...,0); SVG animation scenarios. I would use it to wait for the resources to loaded. If I did a particular check and waited for all the SVG resources. Sometimes you cannot capture the user intent why they set a timeout of zero.
... Developers will hack around it to enable this, it's better to acknowledge this use case and not continue the hack.

JasonWeber: We agree. This hack can impact performance. If we can design an API that doesn't impact performance.

ArvindJain: From the charter perspective, it seems appropriate to put this item there and we can later decide if we want to have this work as a deliverable. Let's start with the email from Microsoft. It's okay to have the paragraph to describe this work at this time.

plh: I do not hear any opposition.

JasonWeber: I'll write a paragraph on that as well.

ArivndJain: The third topic is requestAnimationFrame, is that related to this yield API?

JasonWeber: I think it's unrelated to the yield API. Tony do you want to start?

TonyG: You answered my question earlier, this addresses a different use case of setTimeout(..,0); and orthogonal to setYield...
... it sounds like its important to think about setYield and not completely related to requestAnimationFrame.

<tonyg> http://webstuff.nfshost.com/anim-timing/Overview.html

DougSchepers: The fx task force, web-app, svg, these people do not think it's an exact fit in these WG.
... Speaking for the svg and css folks, this kind of work can be worked on in Web Perf.

plh: Is there interest in the web-perf to take on this work.

JasonWeber: From Microsoft, we would like to pursue something like requestAnimationFrame, to see how natural this would be worked through. We see the general problem is a great topic to work in the Web Perf WG.
... E.g. setInterval(...,10); in script you're doing 100 re-draw that per-second whereas the screen may draw 60Hz. There's additoinal CPU work with no perceived end-user benefit.

Sigborn: How is this related to the visibility API, it appears to cover the same user-cases?

JasonWeber: I think they both benefit perf, they are different patterns the web-dev can use to make their web pages faster.

ArvindJain: From a charter perspective we can handle for the Visibility API and for the requestAnimation frame.

plh: What we care about in the charter is the scope of the work.

DougSchepers: Mozilla has already volunteered an editor.

JasonWeber: I'll write all three of those paragraphs. I'll put them together and send it out.

ArvindJain: That covers all the agenda items in this meeting.
... Are there additional ideas besides these three?
... We should solicit feedback from the WG via email.
... I'll take that.

move to agenda 3

move to agenda 4
Conformance tests, Navigation Timing

TonyG: Let's move the common properties into the webperftestharness.js

NicJansma: Looks good to me.

AndersonQuach: We had issues with replacing the current document.

NicJansma: We agree that we need a test case that shows the difference between in-document modifications versus navigations.

test_navigate_within_document.htm [approved].

test_document_open.htm will be hosted in a sub-frame.

http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_reload.htm

[approved].

http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_client_redirect.htm

TonyG: This test is fine. There maybe another test is to test the navigation types of the frame.
... The test would be a reload on a frame and then subsequently a meta-reload the second time.

Zhiheng: is this good to add to the spec?

TonyG: This would be good.

Zhiheng: I'll add that.

[approved]

http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_attributes_order.htm

TonyG: All the files in the directory should be a test. If something is not designed opened to be test, it should be a resource directory.

NicJansma: That makes sense, great idea.
... Do we agree that the resources linked into the resource directory? and only the entry points exist in the test directory.
... We will refactor test_timing_attributes_order.htm

TonyG: http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_backforward.htm hits an unrelated Chrome bug. In principle I agree with the test. If there's a way to resolve the underlying the bug.
... Worse case scenario is to fall back to a non-automated test.

NicJansma: We looked into other options and didn't find another cross-browser way immediately.

AndersonQuach: One last thing, let's follow-up with unload.

NicJansma: let me referesh with a recommendation. http://lists.w3.org/Archives/Public/public-web-perf/2011Feb/0028.html
... The recommendation is to be consistent with the same processing model and simplify the explaination in cross-domain redirect scenarios. We recommed zero out unloadEventStart and unloadEventEnd.

JamesSimonsen: In Chrome we already have implemented that unloadEventStart and unloadEventEnd in redirect cases.

TonyG: I agree unload event is not valuable enough for the complexity.

AndersonQuach: We're advocating for simplicity for web-developers.

TonyG: I think there's some value in that.
Candidate Recommendation for Navigation Timing

plh: I have not heard objection we can move towards Candidate Recommendation.

Zhiheng: I'd like to add one more sentence about the client-side redirect.

AndersonQuach: This group is ready to move to CR with Navigation Timing.

Resolution: Move Navigation Timing to CR. 4 weeks duration, aiming for March 16.
User Timing

AndersonQuach: The timeline I'd like to aim for is the end of March.

Zhiheng: I think we can shoot for user timings, resource timings may be tough.

AndersonQuach: Let's aim for 3/9 on the API signature.

Zhiheng: There are some differences in the platform preview of IE and the interface in the working draft.

NicJansma: The platform preview didn't have some of the benefits we talked about recently. It was our first take. If we can do something simliar with measures.

PerformanceMarkArray getMarks

typedef sequence<PerformanceMarks> PerformanceMarkArray

interface PerformanceMarks{

readonly attribute DOMString name;

readonly attribute TypedArray marks;

}

{ markName1: 1,2,3 , markName2: 3, 4, 5 };

TonyG: Looks similar to the JSON object, we're using interfaces here instead of the generic object.

http://www.khronos.org/registry/typedarray/specs/latest/

Zhiheng: What about enumeration of the marks and describe in IDL?

TonyG: You can do a for...in loop.

NicJansma: The properties in IE9 are not own attributes. In the case of getMarks, they would not come from a prototype, they are dynamically added. In theory it would work for each and for own properties.
... This approach and enumeration should work for IE properly.

TonyG: What about measures? We left that a bit open from the last call.

AndersonQuach: We saw value with measures in the interface as we put it in the platform preview.

Zhiheng: Seems like there are several use cases, making the parameters second and third optional.

NicJansma: as a refresher, the param list was: markname, startmark and endmark
... We didn't want to allow to pass in an arbitrary time to intermingle different precision of timers.