20,741
edits
Canvas SVG: Difference between revisions
Jump to navigation
Jump to search
→Ideas
(→Ideas) |
(→Ideas) |
||
| Line 24: | Line 24: | ||
* add support for persistence, i.e. to serialize a Canvas.Group structure to disk ($FG_HOME) and use caching from then on | * add support for persistence, i.e. to serialize a Canvas.Group structure to disk ($FG_HOME) and use caching from then on | ||
* run parsexml in a Nasal worker thread (problematic: while parsing/loading can happen asynchronously, the parser needs a handle to the canvas group/canvas FBO to draw into, so need to synchronize access to that) <ref>https://forum.flightgear.org/viewtopic.php?f=4&t=34571&p=368880#p368707</ref> | * run parsexml in a Nasal worker thread (problematic: while parsing/loading can happen asynchronously, the parser needs a handle to the canvas group/canvas FBO to draw into, so need to synchronize access to that) <ref>https://forum.flightgear.org/viewtopic.php?f=4&t=34571&p=368880#p368707</ref> | ||
** 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 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) | * 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) | ||