On 12/17/13 8:36 PM, Rik Cabanier wrote:
I assume that that is the intent of calling createImageBitmap() on a
blob. Since JPEG decoding probably takes significantly longer than
blocking on memory access, I assume that lazy decoding is not really
is there a reason why you are completely decoding the image when you
create the imageBitmap? 
But that misses my point. On the devices I'm concerned with I can never
completely decode the image whether it is deferred or not. If I decode
at full size, apps running in the background are likely to be killed
because of low memory. I need the ability to do the downsampling during
the decoding process, so that there is never the memory impact of
holding the entire full-size image in memory.
If you detect a situation where this operation causes excessive memory
consumption, you could hold on to the compressed data URL and defer
decoding until the point where it is actually needed.
Since exhausting VM will create "undue latency", this workaround
follows the spirit of the spec.
I can't do that because I don't have (and cannot have) a full-size
decoded image. I've got a blob that is a JPEG encoded 5 megapixel
image. And I want to end up with a decoded 320x480 image. And I want
to get from A to B without ever allocating 20mb and decoding the image
at full size.
If you really want to have the downsampled bits in memory, you could
create a canvas and draw your image into it.
Thanks for this link. It looks like the January message quoted in this
July message is requesting exactly the same feature as I am for
discarding or releasing ImageBitmaps.
6) Finally, because image data can take up so much memory, I would
like to propose that ImageBitmap have a release() method to explicitly
free the memory that holds the decoded image when that decoded image
data is no longer needed. This gives web applications more precise
control over memory allocation without having to wait for garbage
There was an email thread on adding this to canvas , it seems
reasonable to add it to imageBitmap as well.