- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 02 Feb 2012 23:24:32 -0800
- To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- CC: public-webapps@w3.org
On 2/2/12 11:08 PM, Bronislav Klučka wrote: > On 3.2.2012 7:51, Charles Pritchard wrote: >> I see no reason why an author should expect to stash 100MB of objects >> into createObjectURL, nor any reason why a UA could not manage 100MB >> for the application lifetime; the user can certainly be informed, as >> they are with other APIs, if the limit has gone beyond what the UA is >> comfortable with. That's always useful for debugging/development -- >> when infinite loops are a normal part of the web experience. > Well how about 1GB video :D or 100 high resolution images? > But as you say.... there's no reason, why desktop application > (browser) should have any problem with it... > And yes... there may be some disk space problems on rare cases, but > such problems can appear in any regular usage of any program (well, > there's simply no space left)... We're going to be treating that video as a media stream via Blob URL. Which is a good point -- it's going to be a Blob url of some sort but it is a special case. That 1GB video is not getting loaded into RAM all at once. A video blob is going to look like some cross of: http://www.w3.org/TR/streamproc/#media-element-extensions http://dev.w3.org/2011/webrtc/editor/webrtc.html http://dev.w3.org/2011/webrtc/editor/webrtc.html#blobcallback It's gonna be messy! Remember, we've got createObjectURL(File) as well, and the mess that can cause, as recently discussed. The underlying File data could disappear from the file system at any time That in mind, my focus is on <img>. And with 100 high res images, believe me: I'm using thumbnails. Not only that, I'm packing 8 thumbnails into each blob/file. So with 100 high res images, we're talking about 12 blobs, less than 60 megs. A lot less now that JPEG is widely supported for Canvas. -Charles
Received on Friday, 3 February 2012 07:24:58 UTC