Canvas SVG: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 14: Line 14:
* Stuart suggested to port svg.nas to C++ (that would still not give us any threading benefits)
* Stuart suggested to port svg.nas to C++ (that would still not give us any threading benefits)


== Status ==
after a bit of googling, it actually turns out that there is already a dedicated plugin for SVG handling via OSG - so that would probably be the least amount of work, given that we already have Canvas::Image using the same ReaderWriter mechanism under the hood.
I don't know anything about the plugin's state - but I suppose it'll we much more feature-complete than our own little parser.
And it being an OSG plugin, it will automatically be able to run in the background - so we won't have to add our own threading code.
Also, it's not a totally new dependency, rather just another OSG plugin - so comparatively easy to support via the existing build system (according to the OSG website, the plugin only needs librsvg)


[[File: Svg-via-canvas-image.png|Native SVG handling via [[Canvas Image]] and the OSG SVG plugin (via librsvg)]]
[[File: Svg-via-canvas-image.png|Native SVG handling via [[Canvas Image]] and the OSG SVG plugin (via librsvg)]]

Revision as of 14:13, 31 May 2020

This article is a stub. You can help the wiki by expanding it.

Background

Some lower end RPi/Intel based computers are taking ~15 seconds to show the FG1000 device.

So there's currently a discussion taking place to optimize/port or re-implement Canvas SVG handling - could some more people please report here how long initialization of the FG1000 is taking for them ? Ideally, by using just the debug menu and checking how much time it takes for the PDF to show up ?

With some new MFDs making heavy use of SVG files, our way of using a custom scripted parser implemented in Nasal (svg.nas) is adding up considerably. i.e. performance is severely affected when processing such files.

On some platforms, just the initialization of the FG1000 is taking ~15 seconds - profiling shows most of the time is spent in ~1500 context switches between Nasal and C++ respectively.

Ideas

  • run parsexml in a Nasal worker thread (problematic: while parsing/loading can happen asynchronously, the parser needs a handle to the canvas group to draw into, so need to synchronize access to that) [1]
  • Stuart suggested to port svg.nas to C++ (that would still not give us any threading benefits)

Status

after a bit of googling, it actually turns out that there is already a dedicated plugin for SVG handling via OSG - so that would probably be the least amount of work, given that we already have Canvas::Image using the same ReaderWriter mechanism under the hood.

I don't know anything about the plugin's state - but I suppose it'll we much more feature-complete than our own little parser. And it being an OSG plugin, it will automatically be able to run in the background - so we won't have to add our own threading code.

Also, it's not a totally new dependency, rather just another OSG plugin - so comparatively easy to support via the existing build system (according to the OSG website, the plugin only needs librsvg)

Native SVG handling via Canvas Image and the OSG SVG plugin (via librsvg)

References

References