[minutes] 2012-09-12 Web Performance WG Teleconference #81

Meeting Summary:



1.       Performance Investment Ideas

Tobie Langel from Facebook and Paul Bakaus from Zynga discussed potential new performance investment ideas with the working group. These ideas are summarized on this thread, http://lists.w3.org/Archives/Public/public-web-perf/2012Sep/0016.html, and the meeting notes.



2.       F2F, Workshop and Survey

We have confirmed November 8th and 9th as the dates for the workshop and F2F meetings, respectively. More data on the venue will be forthcoming. Philippe will forward our performance investment ideas survey to the wider community, https://www.w3.org/2002/09/wbs/1/webperf2012/?login.


Detailed Notes:



Web Perf Teleconference #81 9/12/2012



IRC log: http://www.w3.org/2012/09/12-webperf-irc



Meeting Minutes: http://www.w3.org/2012/09/12-webperf-minutes.html



Attendees

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

Tobie Langel, Paul Bakaus, 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.       Tobie Langel (Facebook) and Paul Bakaus (Zynga) to discuss potential new performance investment ideas

2.       Review draft survey

3.       Close on F2F and Workshop dates

--------------------------------------------------------------------------------
Discuss potential new performance investments

Jatinder: We will hear from Tobie Langel from Facebook and Paul Bakaus from Zynga to discuss potential new performance investment ideas

Tobie: We have found that slow scrolling on mobile devices really hurts user engagements.
... The feeling that the app is something the user doesn't want to use seems to last for days after the one stuttering experience.

<tobie> http://lists.w3.org/Archives/Public/public-coremob/2012Aug/0014.html

Tobie: The conclusion he made in this research was that frame rate calculation on mobile devices are very difficult.
... Something I was hoping that the Web Perf working group could do is create a way to expose the hardware frame rate information to the web platform.

James: We would love to expose to web developers the frame rate from the browser. We are very excited to do this.

Tobie: I would like to concentrate on our use cases. We need to have smooth scrolling and be able to do I/O and change the DOM in the background. E.g., if I scroll to the bottom of the page, an AJAX request goes to grab content to add. Currently this is very hard to do and the whole experience seems very lame.

James: Any proposals on how you would want to see this done?

Tobie: Haven't thought about that to this detail yet.
... Something like what webkit is doing in CSS where a subview can do scrolling with touch and that can be combined with events? A way to do I/O in other threads. Way to pass DOM fragments through post messages. Way to modify the UI through a web worker? A way to append in new content in a way that doesn't hurt performance.
... One ask is to be able to transfer DOM fragments between web workers. I don't have enough information of how browsers are implemented, but would love to understand what we can do to improve this.
... Another thing that we would like is more information on the GPU. Currently the GPU appears to be a black box.
... We have a lot of content in a table like view. Pictures tend to go to the GPU without us understanding how. I don't know what the solution is here; more tooling or APIs to give more information into the GPU.

James: Is this a just a bug of the implementation?

Tobie: Sometimes we just want to understand how big the GPU memory.

Jatinder: If you can pass along some test cases, this could really help us understand your scenario.

Tobie: I'll try to pass along test cases, but no promises.
... In the future, I can provide more information on our scenarios on what we do with table views. This may help.

Plh: That's certainly helpful. Especially the hardware display refresh rate would be something we would do. Jatinder, thoughts?

Jatinder: Yes, that sounds like something this working group should look at. Let's think about this some more.

Paul: We have found that this could be useful. For example, if we are on a monitor that displays at 24hz, and we are using requestAnimationFrame and are assuming we are running at 60 frame per second, we may have issues.
... We would like the browser to give us the display rate.

Jatinder: What about using script to calculate the frame rate? Is it that the average frame rate isn't good enough; you want the instantanous frame rate?

Paul: Yes, that's about it

Plh: Any other issues?

Paul: Another issue we want to look at is memory and GC of memory.

<tobie> ty

Paul: E.g., we have access to the image node but not access into the underlying memory. We do not know if the browser has the image loaded or not in memory. We don't have a reliable way of knowing this. We also do not know reliably when assests are compressed or uncompressed.
... Static assests are also interesting. We would like to understand what is consumed by what. Anything that comes from the server as data, we want to know how much of those resources are consumed as memory in our pages.
... Another is hardware acceleration. We want information on when layers are created and destroyed. When an image is wrapped in a red border and when we translate it, it consumed twice on the GPU, once as an image and the other as the image with a red border around it. I know that this should be a black box, but things like this make bottleneck issues for developers.
... Canvas is another element that is mostly hardware accelerate. For example, we implemented a scrolling map in Canvas with a bounce acceleration effect. We found that two images were okay, but when the third image was added for the bounce effect, we noticed that the animation was slower. The fix was unfortunate as we had to draw the images every time because we couldn't rely on the GPU.
... Have you guys thoughts about this in the WG?

James: We have thought about this internally in Chrome, but we thought there are privacy issues of showing the JavaScript heap, etc.

Paul: Another thing we want is to trigger garbage collection. If there was an event that got trigged when a GC is occuring, so that the app can handle that occurrence. Another things is we want to be able to turn off GC entirely.

Tobie: From a developers point of view, it would be nice if the browser could opt into to a mode where this memory information is accessible in the developer tools.

Alois: I would agree with this as well. As you remember, we discussed memory information for either tooling or now for developer decisions.

Tobie: If any of these features cannot be made available to developers due to fingerprinting etc, we should at least be able to make this available in a standarized way through all browsers in their developer tools.

<plh> https://www.w3.org/2002/09/wbs/1/webperf2012/