W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] Low Memory Event

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 31 Dec 2010 17:35:24 -0800
Message-ID: <4D1E84DC.7090904@jumis.com>

Web Applications may have wildly different use cases than hypertext 

The issue at hand is attempting, in some part, to send a signal to the 
DOM that a low
memory condition exists. This may not happen, but it certainly has 
strong use cases in web apps.

This doesn't mean adding any sort of constraint: it's simply a 
suggestion which the listening
application is free to ignore.

Currently, we can fool around with window.onblur, to try and "guess" 
when responsiveness is less important.

Ian's response to Rob demonstrates something that will always exist: 
Sometimes we switch tabs, and the other tab is a lower priority.
Apple's innovations with the iOS demonstrate how useful events can be, 
for eeking out a little extra stability in constrained environments.

Chrome and Firefox will crash / behave funnily when RAM is short. RAM 
gets short on my machine.
Safari also bails out, on the iOS, when RAM runs out. These can't be 
avoided completely, but they can
easily be mitigated by sending out an event, which the author can use to 
slim-down their environment.

A web application I work on uses Canvas bitmaps as buffers, to speed 
things up, like "Undo", when drawing.
It also uses Canvas to keep image sprites available. Many of these 
buffers can be destroyed at any time,
but doing so would mean they need to be recreated, taking up CPU. It's a 
typical CPU vs RAM trade-off.

If I were to receive an event, letting me know a low memory condition 
exists, I'd drop most of my buffers
immediately, allowing for the machine and my application to carry on 
normally, a little while longer.

This little bit of information sharing means a little bit more stability.

So, again: if low memory, then get rid of unneeded data in the scripting 
environment, such as canvas bitmaps, and state arrays.
The upside, is that the browser would run out of ram a little less 
often. The downside is that there'd be another word in the
large vocabulary of HTML/DOM events.

It may not be time to tackle these kind of issues, but I thought I'd 
give it a shot.

The usefulness has already been proven by iOS applications. We can work 
with low memory events there.
I'd like to be able to listen for them on the desktop as well.

Received on Friday, 31 December 2010 17:35:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC