Re: [whatwg] Handling out of memory issues with getImageData/createImageData

On Mon, Sep 28, 2015 at 5:40 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Sun, Sep 27, 2015 at 6:14 PM, Allen Wirfs-Brock
> <allen@wirfs-brock.com> wrote:
> > Actually, that's not completely correct.  Within ES2015, the only way
> > explicitly allocate a large, dense area of memory is by creating a large
> > ArrayBuffer instance.  All attempts to create such instances eventually
> > perform the actions specified by CreateDataBlock [1].  CreateDataBlock
> > explicitly says that a RangeError exception is thrown if it is
> impossible to
> > allocated the requested memory.
> >
> > I would expect and future ES features that exposed similar allocation
> > capabilities to follow that same pattern.
> >
> > [1]: http://ecma-international.org/ecma-262/6.0/#sec-createbytedatablock
>
> Thank you Allen. It would then make the most sense to rethrow that
> exception for these <canvas> methods (and ImageData constructor). I
> filed https://github.com/whatwg/html/issues/197 to track this. If
> anyone is interested in working on this let me know. It should be a
> relatively straightforward refactoring of the existing descriptions of
> these features.
>
>
Okay. That settles it for me, future sophistication not withstanding.

To give more context on the Canvas/ArrayBuffer specific cases: These APIs
allow apps to request arbitrarily large contiguous memory buffers, so they
are frequent sites of allocation failure errors. Often when an allocation
failure happens in these API's the system is not critically low on memory,
and the rest of the application/browser may very well be able to continue
to function normally. For a long time in Blink, we've been mitigating OOM
crashes by allowing canvases to silently fail when their backing stores
fail to allocate. These failures have been implemented in a way that is
transparent to the javascript code. The only side effect is that the canvas
contents remain blank (I know, it's a big side effect). This strategy has
avoided the confusion issue that Mark explained. The only observable effect
form the app's perspective are when doing canvas readbacks, the results
come back blank.  Whether or not this is an acceptable user experience
depends on the nature of the application and whether or not the canvas is
central to the app, but it is almost always a better user experience than a
crash.

The additional problem we have with the ImageData creation APIs, is that
failing silently is a lot trickier because the APIs must return a valid
ImageData object of the correct size. Failure to do so would not be spec
compliant, could result in a confused state, and would likely result in
some hard to foresee exception being thrown later down the road. What Rik
was suggesting about returning a fake ImageData object would be consistent
with the silent failure/best effort approach we've been using so far, but
it has performance implications that we can't ignore: We would have to add
a conditional branch (or a function pointer indirection) to the
UInt8ClampedArray element accessor to differentiate the fake vs real
behaviors. This is the stuff of inner loops for image processing algorithms.

Throwing a RangeError exception in these cases does seem like the lesser
evil, not to mention that it is what the spec now calls for (thanks Allen).

Received on Monday, 28 September 2015 14:43:51 UTC