svg.nas in v2016.4.3 ,bug or intentionally modified ?

[Hooray]

Referring to the talks and events on the devel list, I can only agree with Thorsten's suggestion: please continue your work, but please make it strictly optional - otherwise, you are touching/affecting tons of functionality that you cannot ever realistically test in its entirety.

In my opinion, the right way to proceed with this would be introducing a dedicated Canvas::Element specifically for SVG processing - and if you do want to touch Canvas::Path, it would be best to make it optional by looking for a corresponding property to enable that new code path - that way, we can also easily patch parsesvg() in svg.nas to look for a corresponding option and use the faster C++ implementation.

But again, it would seem to make more sense to introduce a new Canvas element that supports SVG processing using native code - just like we should be adding new elements for other purposes, rather than creating tons of Nasal code to work around these limitations.

I think you were the one to originally create the raster image element (Canvas::Image), so you are in a pretty good position to take that as a template to come up with a new element specifically for native SVG processing - without touching/using any of the ShivaVG back-end code that you'd like to get rid of.

Equally, the SIMD related changes to Canvas/Shiva should be strictly optional, too - i.e. by introducing a corresponding #IFDEF and/or startup option, otherwise we're changing FlightGear hardware requirements/recommendations without anybody agreeing to do so up-front (or documenting this change after the fact) - right now, that code seems far from mature (unfortunately), so it would be best to keep it optional, and maybe keep it disabled for starters until all the issues have been identified, understood and fixed.