Re: [agenda] Web Performance WG Teleconference #81 Agenda 2012-09-12

Jatinder,

I enjoyed being on the call, thanks again for the invitation. I have prepared notes that I'm happy to share with you all, they're bit more extensive than the IRC transcript:

Memory
While the navigation timing APIs help us understand bottlenecks in our loading time performance, we’d like you to help us analyze what’s happening during runtime.

On mobile devices, the biggest performance bottleneck for large scale, high fidelity apps and games turns out to be memory consumption. As soon as you run out of physical memory, constant swapping occurs and runtime performance of your web project dramatically suffers.

As web developers, we currently have no way of understanding how memory is consumed.
1. Javascript

  *   We don’t know how much memory a newly created object or function allocates
  *   We can’t call the GC manually, and there is no guarantee that calling “delete” will trigger the GC right away

2. Images

  *   We do not have access to the resource of an image, just the DOM representation
  *   We can’t “unload” images reliably
  *   We don’t know when assets are uncompressed
  *   We don’t know when an uncompressed, compressed or both representations of an image is kept in memory and for how long

3. Static assets

  *   Static assets include:
     *   Non-interpreted JavaScript
     *   Stylesheets
     *   Uncompressed images
  *   We want to know how much total memory is consumed by these static assets, as memory is usually shared across all of the above

4. HW Acceleration
This is tricky as it is a platform specific problem, but it doesn’t make it less important. A large number of browsers is using a different render path for content they can hardware accelerate.

Said content is usually composited on the CPU first and then uploaded as a texture to the GPU. At this point, it becomes a “layer” and easy modifications like opacity and moving the layer around to not trigger recreating the layer.

We need information on when layers are created, destroyed and recomposited. We need this to understand performance characteristics, but we also need it to control our total memory heap - an image wrapped in a div with a red border that gets uploaded as a GPU layer consumes twice the amount of uncompressed pixel memory.

We realize and appreciate that browser vendors work hard on abstracting this issue and ideally agree that acceleration should be automatic and no concern to the web developer – but reality shows that we do not have that luxury yet, as false layer management is hazardous.
Canvas
Almost all modern browsers hardware accelerate Canvas nowadays and do so by trying to understand how long a certain texture is needed on the GPU through a set of deterministic algorithms. Unfortunately as developer, this often does more harm than good in an environment when you have to be in full control of the situation. We want to be able to understand when textures are kept in a buffer and when they’re released again.

As a practical example: We have implemented a scrolling worldmap as a proof-of-concept in canvas that you could pan with the mouse/touch, and one viewport was represented by one image drawn to the canvas. At first, we’d always draw two adjacent pictures (so the user never see’s white background), but if you let go of the mouse, we’d do a “bounce” deceleration of the movement that shows the next logical image in the row. As soon as the logic detects that it needs to draw a new image, texture swapping happens in the background (especially visible on iOS) and you will notice a visible hitch (50+ms).  The unfortunate solution was to always draw all three images at any given time, even when one of them was off -screen.
4. Total available memory
We want to be able to query the total available physical memory on the device running the browser (or if it is capped for my web app, the capped size).

Even though it doesn’t guarantee anything, it allows us to better judge what we can do, and what we shouldn’t do.
Display refresh rates
It needs to be understood how much of a real world problem this is, but it is relevant with any screen that isn’t set to 60 Hz or a multiple of it.

We’d like to query the display refresh rate and the rAF interval in order to minimize jutter.
Garbage Collection
We want to be able to:

  *   Trigger garbage collection manually
  *   Understand the execution interval of GC (i.e an event triggered on the window)
  *   Understand the time a GC took (in order to optimize our framerate against it, could be reported through the same event)
  *   Disable GC and only trigger it manually

From: Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>>
Date: Tue, 11 Sep 2012 21:26:44 +0000
To: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>, Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, Tobie Langel <tobie@fb.com<mailto:tobie@fb.com>>
Subject: [agenda] Web Performance WG Teleconference #81 Agenda 2012-09-12
Resent-From: <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Tue, 11 Sep 2012 21:27:30 +0000


Below is the proposed agenda for tomorrow’s meetings.

Zakim Bridge Numbers:
+1.617.761.6200, +33.4.26.46.79.03 and +44.203.318.0479.
Passcode 97373 (WPERF)

IRC channel #webperf on irc.w3.org:6665   http://irc.w3.org/

Working Group First Call (1-2PM EST/10-11AM PST)

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

4.       Any other issues

Working Group Second Call (5-6PM EST/2-3PM PST)
Meeting cancelled.



Thanks,
Jatinder