[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] TypedArrays and mapped memory regions



Hi,


TypedArrays and their underlying ArrayBuffer gives efficient native/direct access and interoperability with low-level languages to memory regions.
Native memory regions do not always have read/write access like assumed right now by the spec though, some native APIs give back read-only or write-only memory regions.

Currently these APIs (eg. such as mmap but also closer to WebGL glMapBuffer, or buffer locking APIs) are not usable from _javascript_ without defining custom 'illegal access' behavior to TypedArrays and/or, worse, writing new custom buffer types altogether to be able to safeguard such invalid access attempts.

IMO being able to write _javascript_ wrappers for such native functions with a common, consistent, well-specified interface such as TypedArrays would be beneficial.
Potential users for this are WebGL extensions, File API, Node.JS(?), etc...


I propose a minimally intrusive addition to the spec to define behavior that makes TypedArrays usage compatible with any mapped memory region :


[addition to ArrayBuffer type spec]

readonly attribute boolean readable;
Read-only property.
True if the the ArrayBuffer contents can be read from, false otherwise.

readonly attribute boolean writable;
Read-only property.
True if the the ArrayBuffer contents can be written to, false otherwise.


[addition to ArrayBuffer constructor spec]

The contents of the ArrayBuffer are initialized to 0 and both readable and writable attributes are true.

[addition to TypedArray getter spec]

If the underlying ArrayBuffer is not readable (readable attribute set to false) an INVALID_ACCESS_ERR is raised.


[addition to TypedArray setter spec]

If the underlying ArrayBuffer is not writable (writable attribute set to false) an INVALID_ACCESS_ERR is raised.



It's the responsibility of _javascript_ native implementors to manage these attributes appropriately with the wrapped API and the _javascript_ engine internally (the access attributes being read-only from _javascript_'s user perspective).

Benefits :
- frontend APIs have consistent illegal access behavior and aren't required to implement/document custom types and behavior over existing TypedArray implementations.
- for some APIs memory usage and GC churning can be greatly reduced as this allows zero-copy mechanisms.


Prospective example with glMapBuffer : (NB: not the only potential user and I do not support its inclusion in WebGL 1.0 of course ;)

array = gl.mapBuffer(GL_ARRAY_BUFFER, GL_WRITEONLY);
//array is writable only
//fill the array with, say, procedurally generated data from an audio waveform
gl.unmapBuffer();
//array is now neither readable or writable as backend storage is unmapped
//any attempt to access its contents will raise an INVALID_ACCESS_ERR



Proposed patch to support this spec addition in Mozilla :
http://neonux.com/webgl/js_readable_writable.patch

Proposed patch to add a helper for native JS code to create an ArrayBuffer from a mapped region :
http://neonux.com/webgl/js_createarraybuffermapped.patch
(patch not required to support the spec addition of course)


Thoughts ?


Regards,