20,741
edits
Line 216: | Line 216: | ||
In general it would be a very worthwhile goal to specifically target SVG because it's an existing standard, so that any Canvas/MFD related efforts could reuse tons of existing tools to help design, develop and maintain avionics or other SVG based functionality. This is also the only sane mechanism to render avionics remotely without replicating tons of code and without requiring a full OpenSceneGraph/osgviewer-based software stack (as per fgpanel or [[FGCanvas]]). | In general it would be a very worthwhile goal to specifically target SVG because it's an existing standard, so that any Canvas/MFD related efforts could reuse tons of existing tools to help design, develop and maintain avionics or other SVG based functionality. This is also the only sane mechanism to render avionics remotely without replicating tons of code and without requiring a full OpenSceneGraph/osgviewer-based software stack (as per fgpanel or [[FGCanvas]]). | ||
A working canvas->serialization scheme would also allow Phi to reuse Canvas-based MFDs without much effort. | A working canvas->serialization scheme would also allow [[Phi]] to reuse Canvas-based MFDs without much effort. | ||
Ultimately, it would be up to the client-side to determine if and how to deal with such a streamed SVG, so that even a remote FlightGear instance could simply decide to render a corresponding SVG in a master/slave fashion. | Ultimately, it would be up to the client-side to determine if and how to deal with such a streamed SVG, so that even a remote FlightGear instance could simply decide to render a corresponding SVG in a master/slave fashion. |