Close and transfer (buffer stealing)

[chcunningham]

@padenot raised idea in editors call to frame.close() -> transfer cpu data immediately to ArrayBuffer. Tracking here to ponder it more.

[dalecurtis]

close() only closes that frame's handle on the frame. It may still be used elsewhere. Given the threading involved, I don't think there's any way to safely steal the buffer except in rare circumstances (RefPtr::HasOneRef() etc).

[padenot]

Yes, this is precisely the case that I mentioned, it can't work otherwise.

I expect this is in fact rather common: you decode, you get a frame, you read it back to apply some custom processing with wasm/js (this means a copy, for now). If this optimization isn't available, then the memory traffic is essentially doubled in the reasonably common case of a software decoder.

[dalecurtis]

I agree, it's a good idea if we can make it work in common scenarios. We may want a separate closeXXX() method or parameter which activates this though for clarity and to avoid always transferring to a GC'd type to avoid increased memory pressure.

That said, a HasOneRef() type solutions has some edges that need solving:

• Frame pools will often be the last ref owner, so upstream clients may never reach a single ref state. Even capture paths may have a frame pool.
• The decoder's refs and the UAs refs are not always the same thing. There must be no refs by the decoder at the point we vend the ArrayBuffer or security issues arise due to the lack of read only JS memory.

Probably more, but that's all I can think of at the moment.