New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: syscall/js: allow passing a slice of bytes directly to JavaScript #46473
Comments
For data, here's a profile of a (relatively simple) game playing a recording showing about 3-4% of the total run time taken by the |
Yes you can use I guess the question is do we want to make such tricks part of the syscall package or let it be something outside the standard library. And moreover, if we do this, then we would now have two ways to pass bytes - one via copying and one without. |
Is there a way to get |
Looks like you can do this to get it:
Should you? Probably not. |
We don't need to modify You can check this commit to see how it was done before the copy functions were introduced: https://github.com/agnivade/shimmer/commit/d08fb873f760d93922e97085a792539e714df4a9/ |
I wish for it too but I'm wondering if it wouldn't require some kind of ownership transfer semantics to avoid the pitfalls of aliasing. |
You still need to access but at least it's possible without language/standard library changes |
What is the problem of change I think that the best option to do that is the following:
The best option is not to use |
In the same way that you can pass a pointer to an element of a byte slice to a function via CGo without copying it, assuming the function you're calling doesn't hold on to the pointer after it returns, it should be possible to call JavaScript functions with a
Uint8Array
that points directly to Go memory.This could be used to make calls to functions like WebGLRenderingContext.bufferData more efficient, as the data wouldn't need to be copied twice (once from Go to JavaScript and then again by the browser).
The same caveats as passing a
*byte
to CGo would apply: if the function you're calling holds on to the pointer after it returns, the pointer will probably eventually point to something else.The text was updated successfully, but these errors were encountered: