Easily switch nodes to use workers

[frading]

Polish the current worker setup. A subnetwork whose nodes are sent to a worker should be able to only copy/shader an attribute buffer (as opposed to transfer a whole geometry, which can be very slow)

[fire]

Can you repeat what you're requesting in more detail? What is the problem being solved?

Typically performance feature enhancements need a target goal because workers typically makes code slower.. but can use more of the cpu's threads.

[frading]

The goal is indeed to improve performance. It could be any of the following situations:

• we allow some operations to perform in parallel on multiple CPUs.
• we send a long operation to a worker, even if that means it taking longer overall. Freeing the main thread is still benefitial as it can then be used for other unrelated javascript code (for instance, any CSS/UI/vuejs/react update that is not tied to the 3D scene )
• we have the full scene running in a worker, maybe with offscreen canvas, and therefore the main thread is free from any webgl work. We would only need to send user events to the worker.

My current thinking is that an easy way for a user to configure which nodes should be sent to a worker would be to wrap them inside a subnet, toggle a parameter useWorker on that subnet, and the node would:

• create a worker based on the given nodes
• know how to query the inputs from the main thread and send the result back
• know if the data that needs to be sent is a full hierarchy of objects, or only a single buffer attribute
• know if some data may not be possible to send (for instance a particle system that is on the GPU), and display a relevant error message.

You could then have middle to large scenes have different groups of nodes in different subnets, each using a different CPUs. This would make it easy to use as many thread as possible.

In order to test this, you could create any node tree with a large input geometry. Or you could also test with the sop/attribTransfer node, which can take a long time by itself when both inputs are large geometries, as each point of the first input will check each point of the second input.

And note that my comment above mentions "the current worker setup", but that's is not existing anymore, as I have not worked on it since then. My knowledge of workers being pretty shallow, this would need to be started from scratch.