Currently we render VDOM to a string for duplicate detection, and then parse that string into xmldom in Node and actual DOM in browser.
[x] We should be able to convert VDOM directly to xmldom/DOM via a simple recursion similar to preact-render-to-string. Need to benchmark, but this should be faster than parsing a string.
[ ] Alternatively, we could avoid xmldom on Node and just work with VDOM for the full document (and use Preact's render if we need to go to actual DOM). Not sure if/when this would be better, but perhaps worth experimenting with. Might also be beneficial for GUI?
[ ] Should we try to do duplicate detection without rendering to string? Maybe stringify nodes and use a Map to recursively find identical root nodes and recurse? Then we could avoid the string intermediate form altogether, except for final rendering to an SVG file. (Currently we stringify individual symbols and also stringify the final SVG file, and we should only have to do the latter.)
preact-render-to-dom benchmarking shows stringifying is only 20% of the stringify + parsing, or 4x faster than parsing, so this ends up being far less important than the first bullet.
Alternatively, we could always work with Preact instead of DOM. Then we wouldn't have to convert Preact at all (but would still have to parse strings). Code gets a little uglier (would need custom setAttribute).
Currently we render VDOM to a string for duplicate detection, and then parse that string into
xmldomin Node and actual DOM in browser.xmldom/DOM via a simple recursion similar topreact-render-to-string. Need to benchmark, but this should be faster than parsing a string.preact-render-to-dombenchmarking shows a performance increase of roughly 7xxmldomon Node and just work with VDOM for the full document (and use Preact'srenderif we need to go to actual DOM). Not sure if/when this would be better, but perhaps worth experimenting with. Might also be beneficial for GUI?preact-render-to-dombenchmarking shows stringifying is only 20% of the stringify + parsing, or 4x faster than parsing, so this ends up being far less important than the first bullet.Alternatively, we could always work with Preact instead of DOM. Then we wouldn't have to convert Preact at all (but would still have to parse strings). Code gets a little uglier (would need custom
setAttribute).