评论
成员
|
您能否上传/链接您的文件,以便我们可以复制您的问题? |
合作者
|
@tbfleming我认为这是达到 redux 更新能力。可以去更新 onBlur 而不是 onChange 吗? |
成员
|
@jorgerobles让我们先看看发生了什么。缓慢的 onChange 将意味着缓慢的 onBlur。不那么频繁,但仍然会很烦人。 |
作者
|
我在这里附上了工作区。在这一点上,我想知道我是否应该只将其作为光栅而不是矢量路径切割来进行。 |
合作者
|
@tbfleming这是一个相当大的文件,但在我的桌面上运行得很好。堵塞物似乎位于工作区选择的矢量动画上,而不是文本框上。 |
合作者
是的,我就是这样做的,没关系:) |
合作者
|
然后转到#216。关闭。 |


我目前正在处理一个非常大(~30MB)的 dxf,它有很多路径。当我在这些路径上添加一个操作,然后尝试编辑路径的“名称”字段时,程序花了一分钟多的时间才完全识别我输入的字母“雕刻”——这些字母出现了一两个长时间“思考”的时间。
我假设发生这种情况是因为某些事件处理程序在操作声明中的所有文本框上捕获 onChange 并导致所有路径的某种迭代。我想知道这是否是有意为之,或者编写代码的人没有意识到它会遇到大量路径。
我的建议是,如果此功能是必需的,我们是否可以有一个启用/禁用处理的切换,而不是在我完成所有必要的操作更改后提供一个按钮来触发该处理(例如光束直径、激光功率、切割率、起始高度等)。有了这个会加快我的切割设置时间。
我会深入研究并自己看一下,但我对 node.js 不是很擅长。