- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 31 Dec 2010 17:35:24 -0800
Regarding: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029575.html Web Applications may have wildly different use cases than hypertext documents. 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. -Charles
Received on Friday, 31 December 2010 17:35:24 UTC