search

LaserWeb / LaserWeb4

Collaborative effort on the next version of LaserWeb / CNCWeb
GNU Affero General Public License v3.0
702 stars 190 forks source link

Multiple WebWorkers for GCODE generation #301

Closed sdesalas closed 7 years ago

sdesalas commented 7 years ago

Hiya,

I've been digging around the GCODE generation and seems to me like this could be improved, both in terms of performance and providing progress % reliably, by using a queue and multiple web workers instead of a single one.

Currently cam-gcode-laser-cut.js and its sibblings (-mill.js, -raster.js) run on the premise that there is a header, a bunch of paths to process and a footer, and the worker stitches it all up in the background, providing progress updates as it goes (though not always very reliably).

Wouldnt it be a better approach to have a queue of X (100?) tasks, each loaded with portion of the paths to follow, process the queue running 2 workers at a time concurrently until its finished, then adding header and footer as needed? The progress % can then be easily calculated by the amount of worker tasks that have been completed.

I'm putting this here to see if anyone else has considered this approach (@tbfleming perhaps?) and discarded it.

tbfleming commented 7 years ago

Separate operations could probably be done in parallel.

jorgerobles commented 7 years ago

I'm putting this here to see if anyone else has considered this approach (@tbfleming perhaps?) and discarded it.

Was me. The idea was exactly the one you expose when did the webworker refactor, but put a lot of work on the "progress bar" part, some people complained that the progress bar stuck for a while.

Will be worthy to take a look again to make use that way, but I don't know if it will speed up the chain. Have to say also, that are different natures of processing. Raster does not behave exactly as the others.

jorgerobles commented 7 years ago

@sdesalas Added 5 concurrent webworkers and ellapsed log. Good catch!