On Sat, Jan 1, 2011 at 5:04 PM, Charles Pritchard <ch...@jumis.com> wrote: > The separation of Mobile and Desktop seems arbitrary, in terms of specs: > if it's useful on the mobile, why would it not be useful on the desktop? > > It's the same concept, a memory warning.
I fully agree that no HTML spec should make a distinction in any way between mobile and desktop. It's an impossible distinction to maintain from a spec perspective, as it's hopelessly blurry--mobile phones having higher and higher specs, iPads straddling the line in the middle, netbooks pushing in from the other direction, and the whole industry being a rapidly moving target that no spec will keep up with. I believe there are differences in practice that make low memory events not very useful on desktops, but that decision should be left to browsers. >> For example, responding to being an idle tab by releasing resources is >> the wrong thing to do if there's plenty of memory available. I have 8 >> GB of memory and Firefox rarely uses more than 512 MB. Don't make me > > I stated, in the example, that it would need more logic to function > appropriately. My point was that the event needs to give enough information to *allow* the application's logic to do this correctly. > They all have the same related meaning: get rid of unnecessary buffers, > serialize and save to disk, if appropriate. > > If I had a lowmemory event on the desktop, I'd run it through the exact same > logic I would on mobile. It just seems easy for this to go badly wrong. For example, suppose an implementation sends lowmemory when the system is low on swap; that is, it's actually running out of virtual memory entirely, and allocations are about to start failing or applications OOM-killed. So, I'm in Photoshop using a lot of memory, stuff gets swapped out, and then when it's nearly out of memory, Firefox notices and broadcasts lowmemory. What happens then? Your application decides to serialize its data and write it to disk, like you say. But your application is already swapped to disk. By accessing all of that data (there must be a lot of it, for it to be worth serializing to disk), you've just forced the OS to swap it all back into memory. It also forced it to swap something else out (probably Photoshop, which I'm trying to use) to make space for it. Serializing the data may use even more memory. This has all just seriously aggrevated the memory condition. Yet, doing that might be a perfectly valid response on a mobile system, where no swap is involved in a low memory condition. (Not entirely accurate--some Android systems compress memory as a swap mechanism.) If applications aren't given enough information to reasonably decide what to do, they'll have a single, universal response which will be correct in some cases and probably incorrect in many others. (Or, they'll have to try to infer what it means based on the browser and platform, which seems to defeat the purpose of speccing it.) -- Glenn Maynard