You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is motivated by a series of other issues with the extension that currently cripple the user experience, in particular the CPU load issues reported (and confirmed by many commenters) in #129. This issue locks up the editor, though some keystrokes still register.
Because this extension renders on every change to the previewed file, I frequently have the extension lock up on an intermediate point (e.g. I've typed half the name of a node), then when it finally finishes, the extension locks up again on a malformed version of the node name. Theoretically there may be some way to fix this through the existing settings, but these are poorly-documented, relying on internal technical details such as when/how rendering requests are created and "blocked."
While the ultimate fix would be to address the CPU load and/or use more flexible, intelligent rendering approaches, these may be beyond the control of the addon (i.e. the result of limitations in an underlying graphviz rendering engine, or VS Code itself). In the meantime, there is one clear change that could reduce the severity of the issue.
The extension should add an option to disable render-on-change, and only render when the file is saved. When a user experiences the problems I described above, they could use this setting to ensure the extension does not brick their VS Code on half-typed edits that were not meant to be rendered yet. This would give them some degree of control over the rendering process, allowing them to ensure renders only occur when they have made a complete edit to the file.
The text was updated successfully, but these errors were encountered:
This is motivated by a series of other issues with the extension that currently cripple the user experience, in particular the CPU load issues reported (and confirmed by many commenters) in #129. This issue locks up the editor, though some keystrokes still register.
Because this extension renders on every change to the previewed file, I frequently have the extension lock up on an intermediate point (e.g. I've typed half the name of a node), then when it finally finishes, the extension locks up again on a malformed version of the node name. Theoretically there may be some way to fix this through the existing settings, but these are poorly-documented, relying on internal technical details such as when/how rendering requests are created and "blocked."
While the ultimate fix would be to address the CPU load and/or use more flexible, intelligent rendering approaches, these may be beyond the control of the addon (i.e. the result of limitations in an underlying graphviz rendering engine, or VS Code itself). In the meantime, there is one clear change that could reduce the severity of the issue.
The extension should add an option to disable render-on-change, and only render when the file is saved. When a user experiences the problems I described above, they could use this setting to ensure the extension does not brick their VS Code on half-typed edits that were not meant to be rendered yet. This would give them some degree of control over the rendering process, allowing them to ensure renders only occur when they have made a complete edit to the file.
The text was updated successfully, but these errors were encountered: