20,741
edits
Howto:Serializing a Canvas to SVG: Difference between revisions
Jump to navigation
Jump to search
Howto:Serializing a Canvas to SVG (view source)
Revision as of 07:32, 30 October 2016
, 30 October 2016→Challenges
| Line 208: | Line 208: | ||
The most difficult part however is dealing with all the edge cases where Canvas based MFDs currently tend to use all sorts of Nasal workarounds to implement FlightGear specific functionality, such as e.g. using different kinds of event handlers and/or animations driven by listeners and properties, because such information does not live anywhere in the global tree currently, so cannot be "serialized back" into SVG space obviously. | The most difficult part however is dealing with all the edge cases where Canvas based MFDs currently tend to use all sorts of Nasal workarounds to implement FlightGear specific functionality, such as e.g. using different kinds of event handlers and/or animations driven by listeners and properties, because such information does not live anywhere in the global tree currently, so cannot be "serialized back" into SVG space obviously. | ||
A temporary solution might be coming up with a shared [[Nasal/JavaScript Subset]] (e.g. a simplified DSL) that can be re/used in both environments. | |||
But in the mid term, it is going to be particularly important to come up with dedicated Canvas elements to abstract away and encapsulate these concepts, so that we can do away with huge custom Nasal blobs, and merely introduce dedicated elements for these purposes, which can be more easily mapped to a corresponding SVG element, e.g. by serializing to an <code><animate></code> tag and a corresponding piece of ECMA/JavaScript code. | |||
Consequently, that also means that we need to move away from tons of custom Nasal blobs, and that even if new functionality may be implemented in Nasal space, it must be registered as conventional Canvas::Element child classes implementing the corresponding interface, for all the reasons discussed at [[Canvas_Development#The_Future_of_Canvas_in_FlightGear]] | Consequently, that also means that we need to move away from tons of custom Nasal blobs, and that even if new functionality may be implemented in Nasal space, it must be registered as conventional Canvas::Element child classes implementing the corresponding interface, for all the reasons discussed at [[Canvas_Development#The_Future_of_Canvas_in_FlightGear]] | ||