WebAssembly is unique, and thus so is AssemblyScript.
In plain JavaScript, arbitrary JS objects (except for certain special ones) cannot be transferred between workers.
But in WebAssembly (and hence AssemblyScript), because everything is buffers, we could potentially do special things like pass objects around (transfer an object's actual bits) from worker to worker, and use them in any worker, and/or reference the same object pointers in a shared heap across workers.
In plain JavaScript, it is therefore hard to make a thread/worker task manager like the idea being made in Three.js, but we may be able to do this fairly easily in AssemblyScript.
In particular, a glas user may be able to tell a worker thread to parse a GLTF file, and that worker can send back fully-usable glas objects (f.e. Mesh, Material, etc). That is not possible in JavaScript, so in that Three.js TaskManager attempt, workers will send processed data back to a main worker (f.e. main thread) and the main worker would still need to construct the regular Three.js objects in order to finally render the scene.
But in glas, a task worker will be able to simply send back usable objects (or pointers) and on the main thread we'll be able to simply render the scene without having to create new objects back in the main thread.
We should first make a basic concept of this multi-thread object passing, perhaps make that a separate lib, then use it in glas.
I think the nature of WebAssembly's binary format may give us a big advantage here...
WebAssembly is unique, and thus so is AssemblyScript.
In plain JavaScript, arbitrary JS objects (except for certain special ones) cannot be transferred between workers.
But in WebAssembly (and hence AssemblyScript), because everything is buffers, we could potentially do special things like pass objects around (transfer an object's actual bits) from worker to worker, and use them in any worker, and/or reference the same object pointers in a shared heap across workers.
In plain JavaScript, it is therefore hard to make a thread/worker task manager like the idea being made in Three.js, but we may be able to do this fairly easily in AssemblyScript.
In particular, a glas user may be able to tell a worker thread to parse a GLTF file, and that worker can send back fully-usable glas objects (f.e. Mesh, Material, etc). That is not possible in JavaScript, so in that Three.js
TaskManagerattempt, workers will send processed data back to a main worker (f.e. main thread) and the main worker would still need to construct the regular Three.js objects in order to finally render the scene.But in glas, a task worker will be able to simply send back usable objects (or pointers) and on the main thread we'll be able to simply render the scene without having to create new objects back in the main thread.
We should first make a basic concept of this multi-thread object passing, perhaps make that a separate lib, then use it in glas.
I think the nature of WebAssembly's binary format may give us a big advantage here...