20,741
edits
(→Ideas) |
|||
Line 28: | Line 28: | ||
** as of 02/2022, Jules has made progress fixing up the property tree implementation to become thread safe, which might make it more feasible to move some parsing/SGPropertyNode processing into a worker thread using a private property tree. | ** as of 02/2022, Jules has made progress fixing up the property tree implementation to become thread safe, which might make it more feasible to move some parsing/SGPropertyNode processing into a worker thread using a private property tree. | ||
* Stuart suggested to port svg.nas to C++ (that would still not give us any threading benefits) - also, our custom parser is really trivial, i.e. only supports a subset of SVG | * Stuart suggested to port svg.nas to C++ (that would still not give us any threading benefits) - also, our custom parser is really trivial, i.e. only supports a subset of SVG | ||
* create a new/dedicated | * create a new/dedicated [[Canvas Element]] specifically for handling SVG files in native code, without going through Nasal space (at least not inside the main loop), possibly adopting an existing SVG rendering back-end that is OpenGL/OSG compatible (see James' Ski/QQ2 comments) | ||
* use an existing SVG back-end that renders into a scene graph, i.e. something like [https://github.com/vega/vega-scenegraph vega scenegraph] (see Scott's comments regarding nanovg) | * use an existing SVG back-end that renders into a scene graph, i.e. something like [https://github.com/vega/vega-scenegraph vega scenegraph] (see Scott's comments regarding nanovg) | ||
* use the librsvg back-end in conjunction with annotations, to expose specific SVG elements via dedicated sc::Element nodes, and treat others as "static" (aka raster images). | * use the librsvg back-end in conjunction with annotations, to expose specific SVG elements via dedicated [[Canvas Element|sc::Element]] nodes, and treat others as "static" (aka raster images). | ||
== Status == | == Status == |