Sharing arraybuffer between worker and native code

[blay]

Hi
I was trying to:
* Receive websocket messages containing images (1MB messages at 60 Hz - or multiples thereof). I use native code using cpprestsdk for this.
* Copy into an arraybuffer created by the native code.
* Use arraybuffer in Javascript to populate a canvas
* Inform native code that arraybuffer is no longer in use. So arraybuffer gets reused - which avoids JS Garbage Collection causing latency spikes in playback. Avoiding the GC is critical for us.

In other words I'm using an approach similar to for sharing a buffer between JS and native code:
https://www.magpcss.org/ceforum/viewtop ... 1&start=30

This works when using the main JS thread.

But I may have as many as 6 canvases and we have found that performance is much better when we handle each canvas in a separate web worker.

I have just noticed that there is no support for integrating native and webworker JS like I need:
https://bitbucket.org/chromiumembedded/ ... indings-or

I doubt that using postMessage from the main thread will be fast enough...

Any thoughts?
Is there any chance that web workers will get support for tighter closer/JS integration?
ben

[magreenblatt]

Is there any chance that web workers will get support for tighter closer/JS integration?

I'm not sure it would improve performance, since V8 is not thread safe and uses a global lock. You might want to instead look at writing the buffers in parallel on separate threads that your application creates, and then signalling in the main thread to have the JS bindings (V8) swap in the changes.

[blay]

Hi
Thanks for your response.

Yes using multiple application threads to write to buffers is the best alternative I could think of.
This would mean making all our calls to canvas context putImageData on the main thread. These calls take a few ms - and If I need to update 6 canvases at 60 Hz I'm probably going to struggle to do that...

I'm not sure it would improve performance, since V8 is not thread safe and uses a global lock.

If I had a separate native thread including websocket connection and everything required for the web worker then I don't think there would be a performance issue with locking. Unless I didn't understand your comment. (In our implementation in standard browser we have many workers each with 1 websocket and 1 canvas. Works well except for garbage collection...)

Arraybuffers are transferable between JS threads. I wonder if it is possible to do that with an array buffer created by native code?
It doesn't look like the JS integration API would have any way of telling a context that the buffer had been transferred.
Anyway I'm dubious it would actually get me anywhere. It would have to avoid garbage collection of the arraybuffers to be useful.

I wonder what other ways there are of getting pixels to screen from native code without using a garbage-collectable JS object?
It looks like the "off screen rendering" feature would hand over total control of the browser client area to the application - but then I wouldn't have access to any of the browser's html rendering I assume.
I guess there's no way to load a WebGL texture in native code that can be accessed by browser?

thanks
ben

[magreenblatt]

You ask good questions. The answers depend on internals of the Chromium/Blink WebGL implementation that I'm not personally familiar with. You might want to build CEF/Chromium locally and explore the code to see what's possible.

[blay]

OK thanks for your comments
ben