16:46:10 RRSAgent has joined #webperf 16:46:10 logging to http://www.w3.org/2011/04/01-webperf-irc 16:46:17 rrsagent, make logs public 16:46:35 Zakim has joined #webperf 16:50:21 Jason: in the ideal, setTimeout would really be 0 16:50:59 James: the odds that people will only properly setImmediate properly on popular websites will be slim 16:51:20 Jason: if we all go into it together, we have the chance to change the behavior 16:56:33 Jason: [shows data] 16:57:25 ... 13% of the sites will use setTimeout(0) 16:57:45 James: but what if they switch to setImmediate()? 16:57:52 Jason: their users will complain 16:58:07 James: no, they'll complain to the browser maker 16:59:10 Jason: I would love to increase by 60% the perf of [unnamed website]... 17:00:06 Cameron: I share the same concern about people misusing the API 17:00:43 ... do website break if you remove the clamp or do they eat the cpu? 17:01:02 James: we only clamp nested setTimeout(0) 17:01:08 s/(0)// 17:01:51 James: the first setTimeout(0) is free for us. if the script goes in a loop, we'll clamp 17:02:40 James: with postMessage, you can build something similar as well. nobody clamp that today... 17:04:11 Jason: I'm not hearing a lot of enthusiast ... 17:04:29 Steve: i'll be interested in doing something with setTimeout(0) 17:05:11 James: we got burned by setTimeout(0), we'll get burn with setImmediate() as well... 17:05:25 ... we'll have to clamp it 17:06:01 Steve: let's call it lockMyCPu() 17:06:09 ... :) 17:06:24 Jason: is there agreement we should do something 17:06:49 James: we're worried about power consumption, but do you change the API or the current implementation? 17:06:56 ... we're working on the implementation side 17:07:10 ... changing the timer, etc. 17:07:25 .... nested setTimeout/setInterval, modifying the clamp 17:07:36 ... lots of things you can do to get better performance 17:07:45 Steve: should we spec those things? 17:09:17 Plh: how about writing some guidelines on how to use setTimeout(0) properly? 17:09:34 Jason: would take time to change the behaviors 17:10:12 Steve: you can also detect the situation and report it possibly 17:11:43 ... evangelism would still be good to do 17:11:56 ... like change setTimeout(0) to setTimeout(16) 17:13:12 Cam: even if the new API gets deployed, it will be a lot of overhead for implementation and won't improve the situation 17:13:42 jamesr: hey! (belated) 17:14:07 James: getting some feedback from javascript devs would be good 17:14:26 s/it will be a lot of overhead/it won't be a lot of overhead/ 17:14:43 s/won't improve the situation/we'll just be in the same situation as now/ 17:15:10 so it's not terrible, if we implement setImmediate and people end up misusing it 17:17:33 Topic: Page Visibility 17:19:55 zakim, room for 4? 17:19:56 ok, plh; conference Team_(webperf)17:19Z scheduled with code 26631 (CONF1) for 60 minutes until 1819Z 17:20:12 zakim, passcode? 17:20:12 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), plh 17:20:48 Team_(webperf)17:19Z has now started 17:20:55 +tomayac_ 17:21:30 +[MicrosoftSVC] 17:22:40 + +1.617.575.aaaa 17:25:28 zakim, drop aaaa 17:25:28 +1.617.575.aaaa is being disconnected 17:25:29 - +1.617.575.aaaa 17:26:08 + +1.617.575.aabb 17:26:51 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0175.html 17:28:31 Arvind: Alex, please talk about this proposal. We are projecting the proposal. 17:28:52 Alex: When a page is being prerendered so it can behave approperiately. 17:29:21 ....There are currently a number of heuristics that a user is viewing your webpage, but there is no 17:29:31 ...good way to determine when you page is not visible. 17:30:10 ...the proposal is only suggesting a few simple APIs. document.visible returns the current visible state of the page. 17:31:32 does visible mean that it's likely that more than 0% of the page is visible? 17:31:38 ....document.visibilityState describes the visible state. When "visible" it is likely that the page is visible. When "hidden" it is guaranteed that the page is hidden. 17:32:11 Arvind: Not sure if everyone knows what pre-rendering is. When a page embeds a link into a page, Chrome will go load the link in a hidden tab before the user clicks on it. 17:32:42 ...the API is mostly motivated by that. So when the user clicks on a link, it will make it really fast because the page is already visible. 17:33:22 ....We're going siginificantly further than current Firefox implementation and loading the entire page. Before the user actually clicks on the link, if we run the script from the hidden page 17:33:45 ...there could be some side effects. This API will help give the visibility so we don't run script before the page is shown. 17:34:44 ...There are other use cases where this is useful. For example, analytics metrics are broken because its not determinstic whether the user is actually looking at a visible page. 17:35:18 ...Jason also mentioned the case where when the tab is actually hidden, we don't want to set as much resources on that page. E.g., When a page is not visible, we don't want to play video if the user can't see it. 17:35:37 ...That was the background. The goal today was let's look at the API and see what we all think about it. 17:36:17 Jason: We agree with the visibility concept. We shouldn't use resources when in background. 17:37:05 ...We had some concerns with the current naming. document.visible may have collisions with other APIs. 17:37:42 Alex: We haven't done any crawls, but with document, someone would have to explictly add to the document name. I don't think this is a common pattern. 17:38:03 Steve: I bet folks are less likely to extend document than window. 17:38:13 Jason: What about other states? We have peek in Windows 7? 17:38:53 Alex: document.visibleState defines a common of states like "preview", something that Windows 7 could use. 17:39:01 Steve: Can it be a value that is not mentioned here? 17:39:19 Alex: The proposal explictly made it clear that future values could be added with a vendor prefix. 17:39:58 Zhiheng: Prerender and cache both seem to be depend on current implementation. Even from a standard point of view, we should make sure the implementation is the same across browsers. 17:40:02 Alex: Couldn't hear you. 17:40:14 Zhiheng: What about prerendering if a browser doesn't implement it? 17:40:55 Steve: Zhiheng's point is that the verbage should be clear that one browser's definition of prerender doesn't differ from another browser, so it would confuse web developers. 17:41:27 Arvind: Zhiheng's other point was cache. 17:41:34 Jatinder: How is the cache value useful? 17:41:50 Alex: We could just move that one and it should be fine. 17:42:28 Ben: Should their be a private state that protects you? 17:42:44 if (page.visible) { showAdAndPlayFanfare(); } 17:42:53 Jatinder: Agree. I wouldn't want an IM chat site to know when I'm not looking at the site and notify other users. 17:43:12 Alex: You can use onBlur() today to see if users are using the site. 17:43:28 Jason: Also, if the site is visible it doesn't mean the user is there. 17:43:35 if (!page.visible) { startFireAlarm(); } 17:43:50 Ben: I'm more worried about the hidden state. 17:44:14 Arvind: We should talk about the two properties. Visible or not and the other one with the states. 17:45:32 Jatinder: Should we make it more granular? I'm in the background tab vs. the computer is asleep. 17:45:50 Alex: We can extend. I can definitely see cases where it's a background tab, or it's hidden. 17:46:04 Alex: We want the prerendered case to help that scenario. 17:46:21 Cameron: You can do the prerender with existing events. 17:46:56 Alex: If we were developing just for prerendered case, we could have made a simpler api. 17:47:09 Jason: The general use case is interesting. 17:48:33 Tony: It'll be interesting to see the difference between sleep and background tab case. Maybe a low battery notification? 17:49:13 Arvind: So the question is, should we go ahead and start working on it? 17:49:59 Jason: I think it's clear that we should do the visibility work. We should start working on the spec. 17:50:26 Steve: It's interesting because from an ad's point of view, this isn't really perf related. But the prerendering makes it perf related. 17:50:34 Steve: Seems like a very useful API. 17:51:51 Arvind: Is there anyone interested in the editing the spec? 17:51:58 James: Is there any more to edit? 17:52:09 Arvind: Yes, this isn't even in the spec format. 17:52:18 Jason: We are willing to help edit. 17:52:21 Arvind: Good. 17:52:37 Cameron: Is this even in the Charter? 17:53:51 Jason: Are we going to remove the cache event? 17:54:05 Alex: I'm fully supported to removing it. 17:54:20 --> http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/sysinfo.html#batteryleveldata_interface Nokia's proposal for battery level 17:54:25 Christian: I don't think it's a particularly useful usecase. 17:54:49 Arvind: From a Chrome's implementation point of view, I think we've only done visible or not. 17:55:19 --> http://bondi.omtp.org/1.1/apis/devicestatus.html The BONDI devicestatus Module 17:55:27 Arvind: isVisible would return false for prerendered case? 17:55:45 Shishir: Yes. 17:56:35 - +1.617.575.aabb 17:56:35 Topic: Paint Notification 17:56:36 -tomayac_ 17:56:37 Moving on to Paint Notification. 18:02:23 Cameron: The goal for the paint notification is to give the browser the ability paint when it needs to. 18:03:26 --> http://blog.pearce.org.nz/2011/03/html5-video-painting-performance.html HTML5 Video painting performance statistics in Firefox 5 18:05:10 Cameron: This is the basic API: window.requestAnimationFrame( function(t) { } 18:05:22 --> https://developer.mozilla.org/en/DOM/window.mozRequestAnimationFrame Mozilla's requestAnimationFrame 18:05:22 Cameron: Slight differences between webkit and mozilla's implementations. 18:06:01 James: Imagine you have a canvas or a banner ad, you can avoid painting for something that is off screen or not visible. 18:06:11 -> http://webstuff.nfshost.com/anim-timing/Overview.html Timing control for script-based animations 18:07:05 zakim, drop Microsoft 18:07:05 sorry, plh, I do not see a party named 'Microsoft' 18:07:09 zakim, drop MicrosoftSVC 18:07:09 [MicrosoftSVC] is being disconnected 18:07:11 Team_(webperf)17:19Z has ended 18:07:13 Attendees were tomayac_, [MicrosoftSVC], +1.617.575.aaaa, +1.617.575.aabb 18:12:12 Jatinder: Why isn't this just simpler like onPaint(func callback)? The UA would determine when is the best time to make the callback, e.g., before you paint. 18:12:38 Jason: Painting and animation frames is a bit complimentary. 18:13:43 Jason: The current API wouldn't give the script the ability to control the paint. 18:14:30 Jason: What happens when you drop to 30Hz, how the script deal with that? 18:14:58 Jason: Would you be able to align the frequency of the paint updates (display frequency) with how often you do the callback? 18:16:58 James: With requestFrameAnimation you can make better decisions, because with setTimeout you don't know why they're doing. 18:17:36 Jason: Let me show a demo. 18:17:54 James: Sure. 18:19:10 Jason: Wouldn't you always want to match the display rate? 18:19:32 James: Not exactly. What if you're video is running at a slower rate and you want your animation to match that? 18:22:08 Jason: Showing http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html 18:22:21 Jason is running an xperf trace. 18:27:11 James: How do you know when to fire the timer? 18:28:32 James: Let's say I'm in a background tab, and I'm running a timer. How do you know when it's related to graphics work? 18:29:47 Jason: We feel that we've solved a lot of these problems by aligning to the display time. 18:30:31 Cameron: Theres not much difference how it's done between setTimeout and requestAnimationFrame 18:32:00 Jason: We should solve the case where you see flicker on a resize. 18:34:01 James: This API has got a lot of good response from the Javascript libraries. 18:34:21 Cameron: I like to know which of things you were discussing, Jason, that would impact that API? 18:34:40 ...the stuff about the vblank didn't seem like a required part. 18:35:08 Jason: The APIs are just fine. I'm not sure what the additional value is that the setInterval model we have today. 18:36:40 Jason: We haven't found cases where we are guessing wrong. I'm a big fan of better APIs in the platform that would solves these problems. But they come with the cost of more cost, learn new patterns, best practices. 18:36:52 James: The interesting thing is the way it interacts with animations APIs. 18:37:59 ..theres work going to improve the ability of frame based animation. 18:38:36 Cameron: There were things you were mentioning like synchronizing the names of the animations. 18:39:21 James: As we get more script control of this animation, right now the script base control is not very powerful. Script based animation and declaritive animation is off on it's own. 18:39:30 tonyg has joined #webperf 18:40:28 Jason: We should make sure that frames are not dropped. Curently it's possible with setInterval, setTimeout 18:48:39 Jason: Does Firefox vblank align? 18:48:43 Cameron: I don't know. 18:49:03 Christian: No, I don't believe so. 18:49:24 Cameron: So you'd always want to drop to 30 frames but never 50 frames? Also half? 18:49:29 Always* half? 18:49:57 Jason: Game developers usually go down to half. 18:50:16 James: Worse is 60, 59, 60. Looks visually bad. 18:50:26 Cameron: Are you looking to building these in as requirements? 18:50:48 Jason: Yes, it would be good to have these are requirements. We should talk to game developers, and partners see what their thinking. 18:51:14 James: It may be difficult to enforce a requirement. Imagine a test case. 18:51:28 James: We want to help provide a consistent rendering experience. That'd be good. 18:53:48 James: I saw most javascript library seems to use setInterval. It shouldn't be hard to change libraries. 18:54:13 Cameron: If you noticed that animation is done, you could always throttled down. 18:54:23 James: It may be hard to tell. 18:55:33 Jason: The objectives seems like you want an ability to throttle down, control frame rate, it would be better if there was a vblank alignment. Do you agree with these objectives? 18:56:07 Cameron: I agree that the vblank alignment would be good for better quality. Not sure how that impacts the API. Maybe a mention in the spec. 18:56:28 Cameron: I should follow up and ask people if their intention was to vblank align with this. 18:57:02 Cameron: Another thing Zhiheng had brought up before was synchronizing with video. Maybe that is something else we can align with. 20:08:16 mdelaney has joined #webperf 20:23:37 jamesr, plh, http://dev.w3.org/html5/spec/timers.html#timers 20:28:01 Zakim has left #webperf 20:41:28 rrsagent, create minutes 20:41:28 I have made the request to generate http://www.w3.org/2011/04/01-webperf-minutes.html Jatinder 20:43:46 rrsagent, please part 20:43:46 I see no action items