JJ, thanks for your recommendation, that was extremely helpful. For now I am using the first approach but will possibly try the second one as well to further reduce blocking time on the main thread.
jj schrieb am Donnerstag, 3. August 2023 um 12:45:03 UTC+2: > I wasn't able to find one that passes back and forth control over the same canvas between a thread and the main thread. This is something that web browsers do not natively support. A canvas is accessible from the main browser thread, and from a Worker only if using the OffscreenCanvas feature. But it cannot be accessed from both simultaneously, or access quickly switched between Worker and a main thread. One model might be to build with -pthread, and then do rendering on the main browser thread, and then pthread_create() a background computation thread, and then have the background computation thread send a message to the main browser thread to pull whatever data it needs from the canvas over to the background pthread. This message sending can be implemented manually, or by using Emscripten's foo__proxy: 'sync' JS directives. Another model would be to build with -pthread -sOFFSCREEN_CANVAS, and then create the rendering context in one worker, and the background computation thread in another worker. Then you can use possibly faster synchronization primitives to ask data from the rendering thread over to the background thread, since the main browser thread cannot synchronously wait to receive any messages, only Workers can. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/16521642-b5d3-4022-8cec-a1773b32cdadn%40googlegroups.com.
