[Bug 28496] Allow Blob constructor to take ownership of ArrayBuffer(View) / invoke DetachArrayBuffer

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28496

--- Comment #7 from Arun <arun@mozilla.com> ---
(In reply to Jonas Sicking from comment #6)
> I don't see anything FirefoxOS specific here.
> 
> If you've done some in-memory processing on a big chunk of data, you'll
> likely have that data in the form of an ArrayBuffer.
> 
> If you then want to write that data to IndexedDB you probably want to write
> it in the form of a Blob. This is especially true for IndexedDB
> implementations which optimize storage of large Blobs in IndexedDB
> (hopefully all of them).
> 
> The only way to do that is by doing |new Blob([arraybuffer])|. However that
> operation requires that the memory buffer is copied. This is both bad for
> performance and doubles the amount of memory used.
> 
> Technically the UA could implement some form of copy-on-write scheme for the
> arraybuffer data. However I think that is very hard to do without
> sacrificing performance of all arraybuffer operations, which is unlikely
> something we want to do. This is why transferring of arraybuffers were
> invented in the first place.
> 
> 
> Adding a Blob constructor which allows declaring which ArrayBuffers should
> be transferred into the Blob seems like a simple addition to the platform.


I understand why we should do this, and why, despite the fact that a
copy-on-write scheme would keep the constructor as is, it is probably
untenable.

I suppose we could have an ArrayBuffers-To-Be-Transferred type of dictionary
argument. But instead of putting it in the constructor, might we not have
something like a transferrableList() method (name TBD) that transfers ownership
(and perhaps appends)?

https://w3c.github.io/FileAPI/#dfn-Blob

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 7 June 2015 07:08:19 UTC