17:00:22 RRSAgent has joined #webperf 17:00:22 logging to http://www.w3.org/2011/02/23-webperf-irc 17:00:25 Sigbjorn has joined #webperf 17:00:26 zakim, list conferences 17:00:33 I see Style_CSS FP()12:00PM, IA_XForms()11:00AM, Team_(wai)15:32Z, VB_VBWG(SCXML)12:00PM, WAI_PF()12:00PM, SW_RDFWG()11:00AM, SW_HCLS(LODD)11:00AM active 17:00:35 also scheduled at this time are RWC_web-per(WPWG)12:00PM, XML_XMLCore()11:30AM, AB_(ABF2F)8:00AM, T&S_EGOV(UseWebTech)12:00PM, INC_SWXG()11:00AM 17:00:42 zakim, this will be web-per 17:00:54 ok, plh; I see RWC_web-per(WPWG)12:00PM scheduled to start now 17:00:56 RWC_web-per(WPWG)12:00PM has now started 17:01:01 +[Microsoft] 17:01:34 +??P15 17:03:00 +??P45 17:03:13 +Plh 17:03:26 tonyg has joined #webperf 17:04:02 zhiheng has joined #webperf 17:04:03 + +1.650.214.aaaa 17:06:01 + +1.650.253.aabb 17:06:43 shepazu has joined #webperf 17:06:52 +Shepazu 17:09:33 AndersonQuach has joined #webperf 17:09:40 list the agenda 17:09:43 clear the agenda 17:10:00 agenda+ Visibility API 17:10:11 agenda+ Efficient JavaScript animation 17:10:21 agenda+ Special Interest Group ideas 17:10:33 agenda+ Conformance tests 17:10:52 agenda+ User Timings and Resource Timings 17:10:58 agenda+ Any other business 17:11:06 present+ Sigborn 17:11:08 present+ TonyG 17:11:11 present+ ArvindJain 17:11:16 present+ JasonWeber 17:11:19 present+ Zhiheng 17:11:27 present+ plh 17:11:30 present+ NicJansma 17:11:33 present+ AndersonQuach 17:11:51 present+DougSchepers 17:11:57 present+ DougSchepers 17:12:07 present+ JatinderMann 17:12:24 present+ WalterVonKoch 17:12:27 move to agenda 1 17:12:35 topic: Visibility API 17:14:07 ArvindJain: http://lists.w3.org/Archives/Public/public-web-perf/2011Feb/0023.html 17:14:56 mdelaney has joined #webperf 17:15:08 JaosnWeber: 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. 17:15:19 s/JaosnWeber/JasonWeber/ 17:15:51 ArvindJain: Some work has started, however it's very early in Chrome. 17:16:04 TonyG: I've seen a demo that works. 17:16:41 ArvindJain: We've been prototyping having two states for the document, visible or not. 17:16:51 JasonWeber: That's a good starting point. 17:17:27 ArvindJain: We've been exploring alternate means to explore visibility or not. 17:17:53 JasonWeber: That's the first of the new APIs in the Web Perf Group to work together for website visibility. 17:18:49 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. 17:19:44 JasonWeber: This is an API that can be designed quickly and take the time to understand the compatibility impact to the web. 17:20:55 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. 17:21:06 q+ 17:21:18 q- 17:21:22 JasonWeber: We can start a working draft before the charter is set. 17:21:26 plh: Correct. 17:21:55 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. 17:22:02 plh: Get this to me before Tuesday. 17:22:32 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. 17:23:44 JasonWeber: 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. 17:24:34 JasonWeber: Ties back to timer resolution relates to different user agents and small setTimeouts. It's a complex topic. 17:25:22 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. 17:25:47 TonyG: I have a question on that, how does this relate to requestAnimation proposal. 17:26:51 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. 17:27:20 JasonWeber: In modern browsers, you end up with lots of little spikes of CPU activities, this is easier when seeing CPU charts and patterns. 17:27:39 TonyG: setTimeout(...,0); in general would break the web. 17:28:02 DougSchepers: Developers aren't really looking to have a timeout of zero. 17:28:37 TonyG: Two use cases, yield to the browser and another is to perform efficient animation. Is that a reasonable summary. 17:28:47 JasonWeber: Yes. 17:29:27 Sigborn: while(true) { //do something }; shouldn't the browser be responsible to stay responsive? 17:30:19 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. 17:31:40 plh: You're advocating new APIs for functionality that exists with current APIs. I'm not sure how this will help current browsers. 17:32:01 JasonWeber: Where this help is really in breadth of devices and low-end devices where CPU efficiency is important. 17:32:19 topic: Efficient CPU usage 17:32:24 move to agenda 2 17:32:44 plh: This is not something Web workers will help with? 17:33:04 JasonWeber: No, I'll put together some CPU charts and code snippets to make it easier to see the problem. 17:33:50 JasonWeber: 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. 17:35:06 DougSchepers: Having it in the charter, and looking at it, is not a forcing function to drive this through to completion. 17:36:17 DougSchepers: 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. 17:36:54 DougSchepers: Developers will hack around it to enable this, it's better to acknowledge this use case and not continue the hack. 17:37:17 JasonWeber: We agree. This hack can impact performance. If we can design an API that doesn't impact performance. 17:38:28 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. 17:38:36 plh: I do not hear any opposition. 17:38:43 JasonWeber: I'll write a paragraph on that as well. 17:39:06 ArivndJain: The third topic is requestAnimationFrame, is that related to this yield API? 17:39:19 JasonWeber: I think it's unrelated to the yield API. Tony do you want to start? 17:39:46 TonyG: You answered my question earlier, this addresses a different use case of setTimeout(..,0); and orthogonal to setYield... 17:40:27 TonyG: it sounds like its important to think about setYield and not completely related to requestAnimationFrame. 17:40:33 http://webstuff.nfshost.com/anim-timing/Overview.html 17:41:38 DougSchepers: The fx task force, web-app, svg, these people do not think it's an exact fit in these WG. 17:42:10 DougSchepers: Speaking for the svg and css folks, this kind of work can be worked on in Web Perf. 17:42:18 plh: Is there interest in the web-perf to take on this work. 17:42:58 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. 17:43:45 JasonWeber: 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. 17:44:11 Sigborn: How is this related to the visibility API, it appears to cover the same user-cases? 17:44:38 JasonWeber: I think they both benefit perf, they are different patterns the web-dev can use to make their web pages faster. 17:45:48 ArvindJain: From a charter perspective we can handle for the Visibility API and for the requestAnimation frame. 17:45:58 plh: What we care about in the charter is the scope of the work. 17:46:50 DougSchepers: Mozilla has already volunteered an editor. 17:47:22 JasonWeber: I'll write all three of those paragraphs. I'll put them together and send it out. 17:47:52 ArvindJain: That covers all the agenda items in this meeting. 17:48:21 ArvindJain: Are there additional ideas besides these three? 17:49:00 ArvindJain: We should solicit feedback from the WG via email. 17:49:05 ArvindJain: I'll take that. 17:49:29 Jatinder has joined #webperf 17:50:12 - +1.650.214.aaaa 17:50:15 -Plh 17:50:25 -??P15 17:50:41 -Shepazu 17:55:24 -[Microsoft] 17:57:59 +[Microsoft] 18:04:00 move to agenda 3 18:04:05 + +1.650.214.aacc 18:04:05 move to agenda 4 18:04:23 topic: Conformance tests, Navigation Timing 18:04:49 +Plh 18:04:55 + +1.650.704.aadd 18:06:39 TonyG: Let's move the common properties into the webperftestharness.js 18:06:47 NicJansma: Looks good to me. 18:08:09 AndersonQuach: We had issues with replacing the current document. 18:08:42 NicJansma: We agree that we need a test case that shows the difference between in-document modifications versus navigations. 18:10:23 test_navigate_within_document.htm [approved]. 18:10:33 test_document_open.htm will be hosted in a sub-frame. 18:11:29 http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_navigation_type_reload.htm 18:11:33 [approved]. 18:11:55 http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_client_redirect.htm 18:13:55 TonyG: This test is fine. There maybe another test is to test the navigation types of the frame. 18:16:12 TonyG: The test would be a reload on a frame and then subsequently a meta-reload the second time. 18:16:21 Zhiheng: is this good to add to the spec? 18:16:26 TonyG: This would be good. 18:16:30 Zhiheng: I'll add that. 18:16:38 [approved] 18:17:19 http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/test_timing_attributes_order.htm 18:18:42 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. 18:18:51 NicJansma: That makes sense, great idea. 18:19:29 NicJansma: Do we agree that the resources linked into the resource directory? and only the entry points exist in the test directory. 18:20:33 NicJansma: We will refactor test_timing_attributes_order.htm 18:21:48 mdelaney has joined #webperf 18:22:02 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. 18:22:37 +Shepazu 18:23:40 TonyG: Worse case scenario is to fall back to a non-automated test. 18:24:06 NicJansma: We looked into other options and didn't find another cross-browser way immediately. 18:26:12 AndersonQuach: One last thing, let's follow-up with unload. 18:26:36 NicJansma: let me referesh with a recommendation. http://lists.w3.org/Archives/Public/public-web-perf/2011Feb/0028.html 18:27:55 NicJansma: 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. 18:29:26 present+ JamesSimonsen 18:30:08 JamesSimonsen: In Chrome we already have implemented that unloadEventStart and unloadEventEnd in redirect cases. 18:30:53 TonyG: I agree unload event is not valuable enough for the complexity. 18:31:59 AndersonQuach: We're advocating for simplicity for web-developers. 18:32:21 TonyG: I think there's some value in that. 18:33:22 topic: Candidate Recommendation for Navigation Timing 18:33:44 plh: I have not heard objection we can move towards Candidate Recommendation. 18:34:47 Zhiheng: I'd like to add one more sentence about the client-side redirect. 18:34:47 - +1.650.704.aadd 18:35:03 AndersonQuach: This group is ready to move to CR with Navigation Timing. 18:35:10 + +1.650.704.aaee 18:35:19 agenda+ Timeline with User Timing and Resource Timing 18:35:21 Resolution: Move Navigation Timing to CR 18:35:24 move to agenda 7 18:35:30 tpoic: Move Navigation Timing to CR 18:36:14 AndersonQuach: The timeline I'd like to aim for is the end of March. 18:36:24 Zhiheng: I think we can shoot for user timings, resource timings may be tough. 18:37:25 AndersonQuach: Let's aim for 3/9 on the API signature. 18:39:01 Zhiheng: There are some differences in the platform preview of IE and the interface in the working draft. 18:39:34 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. 18:41:00 tonyg has joined #webperf 18:41:02 PerformanceMarkArray getMarks 18:41:23 typedef sequence PerformanceMarkArray 18:41:37 interface PerformanceMarks{ 18:41:43 readonly attribute DOMString name; 18:41:51 readonly attribute TypedArray marks; 18:41:53 } 18:43:15 { markName1: 1,2,3 , markName2: 3, 4, 5 }; 18:44:15 TonyG: Looks similar to the JSON object, we're using interfaces here instead of the generic object. 18:47:57 http://www.khronos.org/registry/typedarray/specs/latest/ 18:48:21 - +1.650.253.aabb 18:49:01 Zhiheng: What about enumeration of the marks and describe in IDL? 18:49:11 TonyG: You can do a for...in loop. 18:49:52 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. 18:50:04 NicJansma: This approach and enumeration should work for IE properly. 18:50:38 TonyG: What about measures? We left that a bit open from the last call. 18:52:00 AndersonQuach: We saw value with measures in the interface as we put it in the platform preview. 18:52:29 - +1.650.704.aaee 18:52:31 Zhiheng: Seems like there are several use cases, making the parameters second and third optional. 18:52:51 NicJansma: as a refresher, the param list was: markname, startmark and endmark 18:53:25 NicJansma: We didn't want to allow to pass in an arbitrary time to intermingle different precision of timers. 18:53:49 -Shepazu 18:55:23 q+ 18:57:44 - +1.650.214.aacc 18:57:47 -Plh 18:57:49 -[Microsoft] 18:57:51 -??P45 18:57:52 RWC_web-per(WPWG)12:00PM has ended 18:57:53 Attendees were [Microsoft], Plh, +1.650.214.aaaa, +1.650.253.aabb, Shepazu, +1.650.214.aacc, +1.650.704.aadd, +1.650.704.aaee 18:59:44 I have made the request to generate http://www.w3.org/2011/02/23-webperf-minutes.html plh 19:00:37 Meeting: Web Performance Working Group 19:00:43 Chair: Anderson 19:00:46 I have made the request to generate http://www.w3.org/2011/02/23-webperf-minutes.html plh 19:11:07 plh has left #webperf 19:39:26 shepazu has left #webperf