-1

EDIT:

It ended up being very relevant information that this only happens when the ImageDate comes from WASM, I dont know why this would matter. If anyone knows anything about this behaviour and can explain why this happens with WASM-originated ImageDatas only an answer would be highly appreciated.

I have been developing a website with no weird JS shenanigans, no weird libraries etc. But when trying to pass an ImgData object from a webworker to the main thread using postMessage in chrome, I get null on the other end.

ImageData is supposed to be supported by the structured clone algorithm which is what postMessage uses (postmessage docs). This works in Firefox, and doesnt give any crash/throw/warning in chrome, it just doesnt pass through the data.

console.log(ret); // properly displays the ImageData with data, width and height.
postMessage(ret); // no throw or anything

myWorker.onmessage =  function(e) {
    console.log(e); // e.data==null
    // use e.Data as ImageData, which crashes.
}

If I pass in just a random string for testing it does work properly. Does anyone know what could be going wrong here?

I have tried all the error events for webworkers, but non of them get called, so there is no

J. Aarts
  • 105
  • 2
  • 9
  • are you sending the constructed ImageData object or the underlying imgData.data? eta: looks like you're sending the whole thing, I suggest trying to send the array and the width/height separately – Will Jenkins Dec 17 '20 at 13:20
  • The ImageData, if I send the imgData.data that would just be the Uint8ClampedArray that backs the imageData losing the size, I could try, I didn't think of that. But if that works why wouldn't the ImageData itself work? Edit: THIS WORKS!!! I am very much puzzled on why jsut the ImageData doesnt work, but somehow passing the buffer + size separately and reconstructing it on the main thread works. You can post that as an answer if you want and I can mark it as the solution – J. Aarts Dec 17 '20 at 13:26
  • [Works here](https://jsfiddle.net/tz1r268g/) for me in Chrome 87.0.4280.88 on macOs – Kaiido Dec 17 '20 at 14:00
  • 1
    Yes very weird, that also works for me. I tried making the image very big to see if that was the issue but no. I think I figured it out though, if the backing array is created in wasm, then it does not work, but if I create a new ImageData that is not backed by an originally wasm buffer it works. EDIT: after copying the backing buffer in JS, it does in fact work. – J. Aarts Dec 17 '20 at 14:49
  • So what about you [edit] your question so it has all the information in it and can both receive more attention of someone facing the same issue, and maybe receive better answer/solutions? – Kaiido Dec 18 '20 at 03:13
  • wow that's a real nice way of asking! I will definitely do that after such a nice request. – J. Aarts Dec 18 '20 at 20:05

1 Answers1

1

I don't know why Chrome isn't working but I suggest you try sending the underlying imageData.data array and the width and height separately.

const {data, width, height} = imageData;
postMessage({data, width, height})

You can then re-construct it at the receiving end.

Will Jenkins
  • 7,578
  • 1
  • 20
  • 35