[minutes] Web Performance WG F2F Meeting Agenda 2011-04-01

Thank you everyone for coming out to the F2F meeting last week. It was great to meet you all in person and was a pleasure to host the meeting.

I have provided a high level summary of the charter updates, selected editors and milestone updates. I have also provided the detailed meeting notes further below.

High Level Summary

1. Charter Updates
The following Charter updates were proposed:

- Page Visibility 
An interoperable means for site developers to programmatically determine the current visibility of a document and be notified of visibility changes. 

- Efficient Script Yielding 
An interoperable means for site developers to efficiently yield and receive control flow.

- Display Paint Notifications 
An interoperable and efficient means for site developers to schedule script based animations 


2. Editor for new specifications:
The following editors were selected:

- Page Visibility specification - Arvind Jain and Jatinder Mann
- Efficient Script Yielding specification - Jatinder Mann
- Display Paint Notifications specification - James Robinson and Cameron McCormack


3. Milestone Updates:
The Web Performance WG deliverable schedule has been updated as so:

For Navigation Timing:
- FPWD: October 2010
- LC: January 2011
- CR: February 2011
- PR: April 2011
- Rec: May 2011

For Resource Timing and User Timing:
- FPWD: May 2011
- LC: July 2011
- CR: August 2011
- PR: November 2011
- Rec: December 2011

For Page Visibility, Efficient Script Yielding, and Display Paint Notifications: 
- FPWD: April 2011
- LC: July 2011
- CR: August 2011
- PR: November 2011
- Rec: December 2011

Detailed Meeting Notes:
Web Performance WG F2F Meeting Agenda 2011-04-01
01 April 2011

See also: IRC log at http://www.w3.org/2011/04/01-webperf-irc

Minutes
http://www.w3.org/2011/04/01-webperf-minutes.html

Attendees
Jason Weber 
Steve Souders 
Cameron McCormack 
Tony Gentilcore 
Ben Weigand 
Jatinder Mann 
Seth McLaughlin 
Arvind Jain 
James Robinson 
Philippe Le Hegaret 
Zhiheng Wang 
Christian Biesinger 

Scribe
Philippe Le Hegaret
Jatinder Mann 

Chair
Jason Weber
Arvind Jain

Contents
Agenda:
1. Efficient Script Yielding
2. Page Visibility
3. Paint Notification
4. Select Editors and Charter and Milestone Updates

Details:
<plh> Jason: in the ideal, setTimeout would really be 0

<plh> James: the odds that people will only properly setImmediate properly on popular websites will be slim

<plh> Jason: if we all go into it together, we have the chance to change the behavior

<plh> Jason: [shows data]

<plh> ... 13% of the sites will use setTimeout(0)

<plh> James: but what if they switch to setImmediate()?

<plh> Jason: their users will complain

<plh> James: no, they'll complain to the browser maker

<plh> Jason: I would love to increase by 60% the perf of [unnamed website]...

<plh> Cameron: I share the same concern about people misusing the API

<plh> ... do website break if you remove the clamp or do they eat the cpu?

<plh> James: we only clamp nested setTimeout

<plh> James: the first setTimeout(0) is free for us. if the script goes in a loop, we'll clamp

<plh> James: with postMessage, you can build something similar as well. nobody clamp that today...

<plh> Jason: I'm not hearing a lot of enthusiast ...

<plh> Steve: i'll be interested in doing something with setTimeout(0)

<plh> James: we got burned by setTimeout(0), we'll get burn with setImmediate() as well...

<plh> ... we'll have to clamp it

<plh> Steve: let's call it lockMyCPu()

<plh> ... :)

<plh> Jason: is there agreement we should do something

<plh> James: we're worried about power consumption, but do you change the API or the current implementation?

<plh> ... we're working on the implementation side

<plh> ... changing the timer, etc.

<plh> .... nested setTimeout/setInterval, modifying the clamp

<plh> ... lots of things you can do to get better performance

<plh> Steve: should we spec those things?

<plh> Plh: how about writing some guidelines on how to use setTimeout(0) properly?

<plh> Jason: would take time to change the behaviors

<plh> Steve: you can also detect the situation and report it possibly

<plh> ... evangelism would still be good to do

<plh> ... like change setTimeout(0) to setTimeout(16)

<plh> Cam: even if the new API gets deployed, it won't be a lot of overhead for implementation and we'll just be in the same situation as now

<mdelaney> jamesr: hey! (belated)

<plh> James: getting some feedback from javascript devs would be good

<heycam> so it's not terrible, if we implement setImmediate and people end up misusing it

Page Visibility
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0175.html

Arvind: Alex, please talk about this proposal. We are projecting the proposal.

Alex: When a page is being prerendered so it can behave approperiately.
... There are currently a number of heuristics that a user is viewing your webpage, but there is no
... good way to determine when you page is not visible.
... the proposal is only suggesting a few simple APIs. document.visible returns the current visible state of the page.

<plh> does visible mean that it's likely that more than 0% of the page is visible?

Alex: 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.

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.
... 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.
... 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
... there could be some side effects. This API will help give the visibility so we don't run script before the page is shown.
... 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.
... 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.
... That was the background. The goal today was let's look at the API and see what we all think about it.

Jason: We agree with the visibility concept. We shouldn't use resources when in background.
... We had some concerns with the current naming. document.visible may have collisions with other APIs.

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.

Steve: I bet folks are less likely to extend document than window.

Jason: What about other states? We have peek in Windows 7?

Alex: document.visibleState defines a common of states like "preview", something that Windows 7 could use.

Steve: Can it be a value that is not mentioned here?

Alex: The proposal explictly made it clear that future values could be added with a vendor prefix.

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.

Alex: Couldn't hear you.

Zhiheng: What about prerendering if a browser doesn't implement it?

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.

Arvind: Zhiheng's other point was cache.

Jatinder: How is the cache value useful?

Alex: We could just move that one and it should be fine.

Ben: Should their be a private state that protects you?

<plh> if (page.visible) { showAdAndPlayFanfare(); }

Jatinder: Agree. I wouldn't want an IM chat site to know when I'm not looking at the site and notify other users.

Alex: You can use onBlur() today to see if users are using the site.

Jason: Also, if the site is visible it doesn't mean the user is there.

<plh> if (!page.visible) { startFireAlarm(); }

Ben: I'm more worried about the hidden state.

Arvind: We should talk about the two properties. Visible or not and the other one with the states.

Jatinder: Should we make it more granular? I'm in the background tab vs. the computer is asleep.

Alex: We can extend. I can definitely see cases where it's a background tab, or it's hidden.
... We want the prerendered case to help that scenario.

Cameron: You can do the prerender with existing events.

Alex: If we were developing just for prerendered case, we could have made a simpler api.

Jason: The general use case is interesting.

Tony: It'll be interesting to see the difference between sleep and background tab case. Maybe a low battery notification?

Arvind: So the question is, should we go ahead and start working on it?

Jason: I think it's clear that we should do the visibility work. We should start working on the spec.

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.
... Seems like a very useful API.

Arvind: Is there anyone interested in the editing the spec?

James: Is there any more to edit?

Arvind: Yes, this isn't even in the spec format.

Jason: We are willing to help edit.

Arvind: Good.

Cameron: Is this even in the Charter?

Jason: Are we going to remove the cache event?

Alex: I'm fully supported to removing it.

<plh> --> http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/sysinfo.html#batteryleveldata_interface Nokia's proposal for battery level

Christian: I don't think it's a particularly useful usecase.

Arvind: From a Chrome's implementation point of view, I think we've only done visible or not.

<plh> --> http://bondi.omtp.org/1.1/apis/devicestatus.html The BONDI devicestatus Module

Arvind: isVisible would return false for prerendered case?

Shishir: Yes.

Paint Notification
Moving on to Paint Notification.

Cameron: The goal for the paint notification is to give the browser the ability paint when it needs to.

<plh> --> http://blog.pearce.org.nz/2011/03/html5-video-painting-performance.html HTML5 Video painting performance statistics in Firefox 5

Cameron: This is the basic API: window.requestAnimationFrame( function(t) { }

<plh> --> https://developer.mozilla.org/en/DOM/window.mozRequestAnimationFrame Mozilla's requestAnimationFrame

Cameron: Slight differences between webkit and mozilla's implementations.

James: Imagine you have a canvas or a banner ad, you can avoid painting for something that is off screen or not visible.

<plh> Timing control for script-based animations

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.

Jason: Painting and animation frames is a bit complimentary.
... The current API wouldn't give the script the ability to control the paint.
... What happens when you drop to 30Hz, how the script deal with that?
... Would you be able to align the frequency of the paint updates (display frequency) with how often you do the callback?

James: With requestFrameAnimation you can make better decisions, because with setTimeout you don't know why they're doing.

Jason: Let me show a demo.

James: Sure.

Jason: Wouldn't you always want to match the display rate?

James: Not exactly. What if you're video is running at a slower rate and you want your animation to match that?

Jason: Showing http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html

Jason is running an xperf trace.

James: How do you know when to fire the timer?
... 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?

Jason: We feel that we've solved a lot of these problems by aligning to the display time.

Cameron: Theres not much difference how it's done between setTimeout and requestAnimationFrame

Jason: We should solve the case where you see flicker on a resize.

James: This API has got a lot of good response from the Javascript libraries.

Cameron: I like to know which of things you were discussing, Jason, that would impact that API?
... the stuff about the vblank didn't seem like a required part.

Jason: The APIs are just fine. I'm not sure what the additional value is that the setInterval model we have today.
... 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.

James: The interesting thing is the way it interacts with animations APIs.
... theres work going to improve the ability of frame based animation.

Cameron: There were things you were mentioning like synchronizing the names of the animations.

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.

Jason: We should make sure that frames are not dropped. Curently it's possible with setInterval, setTimeout
... Does Firefox vblank align?

Cameron: I don't know.

Christian: No, I don't believe so.

Cameron: So you'd always want to drop to 30 frames but never 50 frames? Also half?

Always* half?

Jason: Game developers usually go down to half.

James: Worse is 60, 59, 60. Looks visually bad.

Cameron: Are you looking to building these in as requirements?

Jason: Yes, it would be good to have these are requirements. We should talk to game developers, and partners see what their thinking.

James: It may be difficult to enforce a requirement. Imagine a test case.
... We want to help provide a consistent rendering experience. That'd be good.
... I saw most javascript library seems to use setInterval. It shouldn't be hard to change libraries.

Cameron: If you noticed that animation is done, you could always throttled down.

James: It may be hard to tell.

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?

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.
... I should follow up and ask people if their intention was to vblank align with this.
... Another thing Zhiheng had brought up before was synchronizing with video. Maybe that is something else we can align with.

<heycam> jamesr, plh, http://dev.w3.org/html5/spec/timers.html#timers

Received on Wednesday, 6 April 2011 00:58:44 UTC