以下是影响速度的因素：

• 曲线到线转换后的点数（lw.svg-parser 控制这个）
• 路径复杂度
• 覆盖路径所需的光栅线数

路径复杂性很难衡量，也更难解释，但起着巨大的作用。下面是它的一部分是如何与这个 SVG 一起发挥作用的：

CAM 的多边形操作依赖于扫描线算法。扫描线（上方的蓝线）始终是垂直的。光栅线（黑色）由用户控制。时间随着：

• 路径到路径和路径到栅格交叉点的数量
• 每条扫描线的交点数：
  • 路径
  • 光栅线
• 扫描线数。曲线到线转换后，每个唯一的 X 坐标都有一条扫描线。
• 我忘记的其他方面

@tbfleming感谢您的深入解释。
我们一直注意到的是，在任何事情似乎正在发生之前的这种很长的停顿导致用户认为出了什么问题。
有没有办法在这个计算过程发生时报告进度并在生成进度条中显示？

我们所能期望的最好结果是用一系列命名步骤替换数字。不幸的是，大多数步骤都没有衡量进展的好方法；他们在完成时就完成了，他们无法预测何时。

上面的设计用了 2 分 20 秒来生成填充路径。
0.1 线宽，100x100mm
进度条一直停留在 0% 直到最后 2 秒。

此设计用了 5 分 15 秒来生成填充路径。
0.1线宽，100x123mm

@tbfleming也许有一些速度优化可以帮助减少这些时间？
相比之下，光栅 gcode 生成快如闪电。

可能有潜在的优化。

@tbfleming我认为滞后是在飞行前（examineDocTree）

如何将矢量数据转换为光栅图形并使用光栅 gcode 生成器为填充操作创建 gcode？这能加快这个过程吗？

@cprezzi我在想同样的事。当前的“线条填充”并不完全是光栅。我已经看到它在我身上跳来跳去……降低效率。

@cprezzi转换为位图是一个公平的解决方案（可以根据需要在其他地方使用），我们甚至可以提出作为一个新的“工具”，从而可以更容易地在设计工具中进行选择。

线填充并不意味着是光栅。有些情况下光栅会产生更好的结果，有些情况下线填充会产生更好的结果。添加将路径转换为位图的功能以便用户可以选择会很好。

@tbfleming，我一直在想转换为光栅所需的路径是计算激光填充的结果，否则它会显示空心形状。所以计算问题不会得到解决：|

@DarklyLabs 最好只在设计工具上光栅化复杂形状，并保留矢量以完成轮廓。

@jorgerobles如果矢量数据具有填充颜色（或您将其设置为）并发布到画布上，那么您将获得带有用于光栅处理的填充的光栅图片。

@tbfleming我认为滞后是在飞行前（examineDocTree）

该死。这是最糟糕的地方，因为通常 examineDocTree 大部分时间都花在 Clipper 上。我希望在那之后。

我只是试图验证但无法验证的位置：Uncaught Error: Cannot find module "socket.io-client"。

@tbfleming运行npm run installdevdev-es6 已与 dev_comms 合并

@jorgerobles我做到了。

@tbfleming我已经尽可能优雅地在 Preflight 上添加了进度。
我已经缩小了对 Gcode 表示的滞后。它的计算相当好，但需要 +6 分钟才能显示在工作区上。

workspace_fill_lag.json.txt

@jorgerobles在此之后我无法生成任何东西。

我测试了@DarklyLabs 文件，预检计算有 1 分 20 秒的延迟。

工作区：twirl2-workspace.json.txt

@DarklyLabs 在 AI 上打开并破坏复合对象的相同文件，持续一半生成。
twirl1.svg.zip

@cojarbi它会抛出任何调试错误吗？我打开的所有文件都运行良好

@jorgerobles我没有得到任何关于光栅的信息。
取决于物体填充路径和激光切割是否有效

第一张图片用于光栅

第二张图是路径

也在 npm 启动时在终端上获取它。

@jorgerobles在进度条中测试新版本机智飞行前。它很快移动到 50%，然后等待完成。这仍然比以前的结果好得多，因为它向用户展示了该过程正在发生。

我们在移除复合路径的情况下测试了旋转，并获得了完全相同的处理时间（2 分 20 秒）。不过，它确实更快地导入了 svg 文件。

twirl_DL.json.txt

在70801d5中修复了缺失的模块

@cojarbi，npm 启动日志是正确的。请附上引发调用堆栈问题的文件。

@tbfleming该模块通常不需要手动添加，因为节点服务器默认为它提供服务。你也启动服务器了吗？

但我发现：每次更新 lw.comm-server 时，我都需要删除 lw4 的 node_modules 子文件夹中的 lw-comm-server 文件夹，然后再次执行 installdev。它不会自动更新。我做错了什么？

@jorgerobles这是上面的文件。我认为问题是它有无数的路径没有加入。如果是这种情况并且这可能发生在其他用户身上，从而造成支持问题，我们能否得到一个错误来显示“去修复你的文件”？

如果我加入所有它有效的路径

0001.svg.txt

但我发现：每次更新 lw.comm-server 时，我都需要删除 lw4 的 node_modules 子文件夹中的 lw-comm-server 文件夹，然后再次执行 installdev。它不会自动更新。我做错了什么？

如果您运行 installdev 而不删除它，它会更新吗？

@tbfleming不，它没有。

@cojarbi这是一个好主意，但必须弄清楚如何做到这一点。

刚刚更新了标签。到目前为止，矢量填充的处理速度和加载平均复杂度矢量文档后的一般交互性减慢一直是我们用户讨论最多的缺点。

@jorgerobles @tbfleming
我刚刚对显示缓存和填充操作进行了一些测试：

构建：4.0.989
OSX

显示缓存 = 关闭，线程 = 2
完成时间 = 3 分 22 秒

显示缓存 = 关闭，线程 = 4
完成时间 = 4 分 24 秒

显示缓存 = 打开，线程：2 或 4
完成时间 = 1 分 9 秒

为什么显示缓存对填充性能有这么大的影响？

显示缓存会停止所有 webgl 渲染，直到在工作区触发事件，从而降低 gpu 消耗。我认为 webgl 在某些情况下不是使用 gpu 而是 cpu，尽管有 chrome 设置。这可能是一个 os/chrome 相关的问题

另外，不得不说，线程系统并不是真正在同一个操作上并发，而是在几个操作上并发。

我猜测@jorgerobles是对的。

尽可能快地关闭。

我可能找到了解决方法。我有一个 SVG 需要大约 10m 才能完成生成 gcode。我尝试将它加载到 inkscape 并将所有曲线转换为非常短的直线段（选择所有路径中的所有节点，单击“添加节点”3 次左右，转换为直线段，保存）inkscape 在此过程中有点滞后但只有不到一分钟，整个过程大约需要一分钟。
它使该文件的 gcode 生成时间缩短到 40 秒，而且曲线质量没有损失！

也许有某种方法可以在 LaserWeb 本身中实现它？我对编码知识不多，

@nipunawg只需将我们的选项GCODE CURVE LINEARIZATION FACTOR（在 LW settings->gcode 中）设置为 0.5 或更大的值，您就可以达到相同的结果。