[Webkit-unassigned] [Bug 120112] Typed Arrays have no public facing API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=120112

--- Comment #22 from Dominic Szablewski <dominic.szablewski at gmail.com> ---
So, I have now changed the phrasing in my implementation as suggested by Geoffrey Garen:

JS_EXPORT JSTypedArrayType JSObjectGetTypedArrayType(JSContextRef ctx, JSObjectRef object);
JS_EXPORT JSObjectRef JSObjectMakeTypedArray(JSContextRef ctx, JSTypedArrayType arrayType, size_t numElements);
JS_EXPORT void * JSObjectGetTypedArrayDataPtr(JSContextRef ctx, JSObjectRef object, size_t* byteLength);

See: https://github.com/phoboslab/JavaScriptCore-iOS/commit/ac4a76470f5adfa592846466f2f8a84d868c053f

While this follows the JSC naming scheme, it also makes the API a bit more cumbersome to use: now, every time you want to get the data pointer or type of a typed array, you first have to check if the JSValueRef you got in your function call is a JSObjectRef (using JSValueIsObject()). Allowing for JSValues to be passed into these functions (i.e. "JSValueGetTypedArrayDataPtr") would be much more convenient, but also not reflect the truth that a Typed Array is a JSObject, not a JSValue.


To answer a few of the questions here:

> [JSObjectMakeTypedArray] What happens when arrayType is kJSTypedArrayTypeNone? or kJSTypedArrayTypeArrayBuffer? 
In case of kJSTypedArrayTypeNone the function returns NULL. In case of kJSTypedArrayTypeArrayBuffer the function returns an ArrayBuffer with the specified number of elements (i.e. bytes), similar to JS ArrayBuffer constructor (new ArrayBuffer(length)).


> Can you clarify what the caller must do to ensure that the returned pointer continues to point to valid memory? 
My assumption was that a call to JSValueProtect() on the Typed Array would also ensure the pointer remains valid, but I'm not really sure if that's actually the case. Maybe Filip Pizlo can chime in: when/how exactly is the underlying buffer "pinned"?

If JSValueProtect() indeed already ensures the pointer remains valid, I don't think we need another set of functions to retain/release the data pointer. Imho it's obvious that if the JSObject is GC'ed, the pointer will become invalid. If you want to hold on to the pointer, hold on to the JSObject.


> Why does getting the data pointer require a byte length?
I found that if you want to obtain the data pointer of a Typed Array, you almost always also need to get the byte length of that data. Note that the pointer to the size_t you pass in, is only used for output! Having two separate API calls for this seemed wasteful. If you don't need the byte length, simply pass NULL instead of a pointer to a size_t:
void * ptr = JSObjectGetTypedArrayDataPtr(ctx, object, NULL);


> Why do we use byte length for access but element count for creation?
JSObjectGetTypedArrayDataPtr() returns a pointer to raw data. If we were to return the element count instead of the byte length, you would always need to call JSObjectGetTypedArrayType() as well, to figure out how many bytes you could access. Using the byte length here greatly simplifies stuff like memcpy() to/from own buffers for API users.

Likewise, we use an element count for JSObjectMakeTypedArray() because 
1) you know the type of the Typed Array you want to create anyway
2) usually you know the number of elements you want to store when creating a Typed Array through the API (this is different from being passed a Typed Array from JS Land!)
3) using a byte length here would be error prone: what if I try to create a Uint32Array with a byte length of 5?


> How do you create a typed array with a data pointer? Is the input a void*?
I don't think we need an API for this. Just let JSC handle the data allocation and then obtain a pointer to it.

JSObjectRef array = JSObjectMakeTypedArray(ctx, kJSTypedArrayTypeUint8Array, 1024);
void *dataPtr = JSObjectGetTypedArrayDataPtr(ctx, array, NULL);
memcpy(dataPtr, myOwnData, 1024);

Imho it's not worth to complicate the API to avoid a short memcpy() for handing over data to JS Land.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151013/8b87828f/attachment.html>