jsx

Documentation

Overview

Package jsx provides essential JavaScript functions that are used widely in wgpu and are very useful for an wasm / js application.

Index

• func Await(promise js.Value) (result js.Value, ok bool)
• func BytesToJS(b []byte) js.Value

Functions

func Await

func Await(promise js.Value) (result js.Value, ok bool)

Await is a helper function equivalent to await in JS. It is copied from https://go-review.googlesource.com/c/go/+/150917/

func BytesToJS

func BytesToJS(b []byte) js.Value

BytesToJS copies the given bytes into a freshly allocated, JS-owned Uint8Array and returns it.

It deliberately does NOT construct a zero-copy typed-array view over the Go wasm linear memory (globalThis.wasm.instance.exports.mem.buffer). Such a view aliases the heap's backing ArrayBuffer, which the Go runtime DETACHES whenever it grows linear memory (memory.grow). A grow can land at any time a Go allocation happens — including inside syscall/js's own makeArgs while marshalling the constructor arguments, or in the makeArgs of the outer queue.writeBuffer/writeTexture Call that consumes the view — leaving the view pointing at a detached buffer and throwing "Cannot perform Construct on a detached ArrayBuffer" (trendvidia/fyne#347). Reading mem.buffer "fresh" does not help, because the detach happens between the fresh read and the construction/consumption.

Copying via js.CopyBytesToJS sidesteps this entirely: the host copy reads mem.buffer atomically with no interleaved Go allocation, and the returned array is backed by its own JS ArrayBuffer, so a later memory.grow cannot detach it. The result is consumed synchronously by writeBuffer/writeTexture, so the extra copy is short-lived.