feat: implement HEAPU8C

[ThaUnknown]

This adds HEAPU8C for Uint8ClampedArray, alongside all the other typed arrays.

This is useful for any WASM library which renders custom image data or bitmaps to a canvas, this is because the fastest ways to paint on a canvas is via ImageData which only accepts uint8c, with this one can directly do

new ImageData(HEAPU8C.subarray(pointer, pointer + size), height)

which is insanely fast, previously to get this functionality one needed to use pre-worker and use:

updateMemoryViews = (_super => {
  return () => {
    _super()
    self.HEAPU8C = new Uint8ClampedArray(wasmMemory.buffer)
  }
})(updateMemoryViews)

[sbc100]

Would it be to expensive to just do new Uint8ClampedArray(wasmMemory.buffer) in your code whenever you need to access this? I think creating a new view should be very cheap, no?

[sbc100]

Would it be to expensive to just do new Uint8ClampedArray(wasmMemory.buffer) in your code whenever you need to access this? I think creating a new view should be very cheap, no?

The reason I'm suggesting this is because we try to avoiding adding code size overhead to the generated code, especially when its not used common cases.

[ThaUnknown]

Would it be to expensive to just do new Uint8ClampedArray(wasmMemory.buffer) in your code whenever you need to access this? I think creating a new view should be very cheap, no?

definitely expensive, if you're outputting any form of rendering, you'd run this a few hundred to a few thousand times a second, it adds up

[ThaUnknown]

Would it be to expensive to just do new Uint8ClampedArray(wasmMemory.buffer) in your code whenever you need to access this? I think creating a new view should be very cheap, no?

The reason I'm suggesting this is because we try to avoiding adding code size overhead to the generated code, especially when its not used common cases.

closure compiler would get rid of it

[sbc100]

But, are you calling new ImageData hundreds or thousands of times a second? Perhaps I'm misunderstanding something. If you are rendering to a region of memory, isn't that don't directly from native code, with the export to ImageData happening infrequently?

From the test failures maybe closure is not able to eliminate this extra size..it looks like its adding 103 bytes to the size of the output?

[ThaUnknown]

yes i'm also calling imagedata a lot of times, but that really can't be changed, as web doesn't provide a better way of rendering data on a canvas
my workflow looks like this: get request in js, call wasm, generate data in wasm, process data in wasm, exit wasm, read processed data directly from wasm heap into imagedata, render imagedata

hm, i'm not sure how else to handle this if closure doesn't eliminate it :/

[sbc100]

yes i'm also calling imagedata a lot of times, but that really can't be changed, as web doesn't provide a better way of rendering data on a canvas my workflow looks like this: get request in js, call wasm, generate data in wasm, process data in wasm, exit wasm, read processed data directly from wasm heap into imagedata, render imagedata

Have you compared the performance of you program with:

 new ImageData(HEAPU8C.subarray(pointer, pointer + size), height)

vs

 new ImageData(new Uint8ClampedArray(wasmMemory.buffer).subarray(pointer, pointer + size), height)

It seems like the new ImageData or the operation you then do on that object would far outwheigh the cost of the new Uint8ClampedArra.

Also, does your program need memory growth? If not you can simply create the new Uint8ClampedArray once.

hm, i'm not sure how else to handle this if closure doesn't eliminate it :/