Closed sdesalas closed 7 years ago
Separate operations could probably be done in parallel.
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.
@sdesalas Added 5 concurrent webworkers and ellapsed log. Good catch!
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.