[whatwg] Low Memory Event

[timeless]

On 9/28/10, Rob Evans <rob at mtn-i.com> wrote:
> All good points. I think as we have moved away from simple web pages and
> really start to think about applications that are coded in js, many things
> previously the exclusive domain of desktop apps are more and more desirable
> for web apps.

Unfortunately, moving away from simple pages introduces pain points
previously only experienced in desktop applications. Browser design
should aim to avoid exposing such pain points.

> I also think that a web page should be able to request exclusive access to
> the graphics card just like many native games do,

> and that the user need not
> be aware that anything different has occurred because the browser can simply
> pause other processes that are not in focus.

We implemented this for the browser in Maemo 5. It means that
basically all Google "applications" break when you switch windows.
Imagine trying to use Gmail only to discover it's broken. It was a
terrible idea. It still *is* a terrible idea. Note that this was
implemented by suspending JavaScript (in a bad way), not by suspending
painting -- painting generally stops anyway when a window isn't
visible.

Gmail has a couple of features which need to work while backgrounded,
one is "new mail notifications" (or updates to the live window),
another is "new chats"/"new chat messages". You wouldn't like not
being able to get calls or sms's while playing a game, and mail/im is
the same (which is why the Maemo presence system doesn't kill itself
when you run an application...).

Only an application knows what should be done when backgrounded. But
some forms of backgrounding shouldn't really be exposed to apps. I
don't want an interstitial page to recognize that I'm ignoring it --
sadly, the future is in this direction, interactive ads which block
content views until they're dismissed.

> I realise the technical aspects of doing that are mega complex. For one,
> each process that is currently using the gpu would need to be signaled that
> it no longer has access at the moment and to pause itself, but then again,
> desktop apps have had to deal with these events for ages.

Desktop apps and mobile apps (especially on Maemo) often don't pay
attention to such details. They continue painting and doing work --
because the user doesn't care and didn't complain. On a desktop
computer, with a power cable, background processes don't matter much,
and to some extent users have learned to kill background tasks when
things get sluggish. Before we introduce more web features, we need to
find out if we can teach users similar things for web apps. People I
spoke to yesterday (traveling is great) all had iOS3 devices and they
understood that when one page was open everything else was dead (they
didn't necessarily like it, one complained about Skype dying when
"switching" to something else), they also understood that this doesn't
happen on the desktop and didn't expect it to happen there. None of
them really thought about how to manage such resources, but to some
extent they had selected optiminal window/tab limits for themselves.
It'd be nice to know if Safari on iOS3 sends events to pages when the
user switches "away" and "back", I've assumed it just saves a picture
and reloads the page.

> It's been a while but I remember coding a similar event handler for when a
> user pressed the windows key and suddenly my game was minimised. If I
> remember correctly, I had to re-initialise direct x or open gl before I
> could continue processing.

Part of using a web framework has involved shielding devs from that pain.

However my understanding of the Linux/Maemo behavior w/ GLES2 is that
one application has no ability to kick out other applications'
surfaces (and some are used by compositors -- which are necessary). I
do remember Windows applications getting blanked out when they lost
focus, but this also matches GDI damage behavior and doesn't match
classic HTML behavior (Canvas might be different here).

Imagine a user loads 2 html-canvas3d games. Imagine that the system
doesn't have much memory and that the user is paying for bandwidth
(I'm in .ie w/ .uk and .fi sims -- I'm roaming, it's expensive). Is
the user going to be happy with you trying to store your inactive game
in DOM/JS (which causes swapping) and then with you trying to use the
network as a storage? The right thing to do is to recognize your FPS
has dropped to "unusable", try decreasing the size of your surfaces,
failing that, pause the game *yourself* and ask the user what to do.
What will probably happen is *nothing* for a while - because the user
was doing something else (playing the other game). Maybe the user just
wanted you to load your resources and went to play tetris3d while
waiting.

> Can't we have something similar on a browser with js events?

As I tried to explain, they turned out to be incredibly
unreliable/unusable for non browser applications (Maemo 5). At least
on Maemo 5 the low memory events (which were at least sort of used in
Maemo 4) are effectively never delivered. The system has 256mb of ram
(128mb is vaguely available to apps) and 764mb of swap (which prevents
low memory signals from being fired until after the system swaps to
death).Again, calculating FPS drops can detect either swapping or
backgrounding -- the desired behavior for both is that your app
suspend its nonessential tasks.

We really can't even try to expose low memory notifications before
browsers manage to get useful ones from the platform (Mozilla has been
trying to do this for the 10+ years I've been working on it -- with no
success). Nor can we do it until browsers manage to do something
useful in low memory situations. Today, the *goal* of a browser when
it's low on memory is to _commit suicide_ *before* an evil web site
exploits its miscalculation. A non goal here is /helping/ that evil
guy determine where the risk point is. Typically what has happened for
perhaps 20 or more years in desktop/web applications is that low
memory conditions lead to "code execution vulnerabilities".


Anyway, for now, instead of pleading, please try working with what you
have. Once webworkers, taskmanagers, resource monitoring is exposed to
users, we can look into what should be exposed to apps. Please
remember that "the editor" will address threads eventually, but that
only new input (use cases, experience) is valuable.

I'm going to take a hike through the Gap of Dunloe. If there's more
here, I'll read it next week.