Detach codec inputs (where feasible)

[chcunningham]

ImageDecoder isn't in the draft spec yet, but see here for latest interface in Chromium.

This is issue is a reminder that we should consider specifying that inputs are detached after the call to decode returns (neutering the buffer from JS pov). Similar to WebAudio's decodeAudio(). Detaching the inputs transfers ownership for the UA to safely perform asynch decoding without requiring a copy.

[sandersdan]

Previously we decided against this for two reasons:

1. It's not compatible with SharedArrayBuffer. In retrospect, it's probably fine to fall back to copying in this case, but that would mean inconsistent behavior.

2. It doesn't allow the input buffers to be reused, and therefore creates extra GC pressure. In practice it doesn't seem like this garbage is consequential.

The primary alternative to transferring inputs is to always copy inputs immediately.

[chcunningham]

Title update: problem isn't unique to ImageDecoder. Lets fix this everywhere.

Agree with points 1 and 2 above.

[chcunningham]

Dropping some questions for TAG

• is it better to always transfer when possible (e.g. yes for ArrayBuffer and ArrayBufferView, no for SAB) or to make it user configurable (e.g. transfer list)? For reference, inputs to WebAudio's decodeAudioData() are automatically transferred.
• if configurable, is a transfer list the recommended approach? We've also considered dual static create methods like EncodedVideoChunk::TransferFrom() and EncodedVideoChunk::CopyFrom().

[padenot]

2\. It doesn't allow the input buffers to be reused, and therefore creates extra GC pressure. In practice it doesn't seem like this garbage is consequential.

There are evidences in the Web Audio issue tracker that folks in the video game industry find this problematic and like "zero-garbage" paths.

I don't have a solution however, but a chat with representatives from this industry is planned.

[padenot]

An update after talking with a couple of people from different industries: it's getting increasingly clear that detaching is needed, but that also internal copy is useful. We'll probably have to support both.