20,741
edits
Canvas sandbox: Difference between revisions
Jump to navigation
Jump to search
m
→CanvasNasal
No edit summary |
m (→CanvasNasal) |
||
| Line 261: | Line 261: | ||
== CanvasNasal == | == CanvasNasal == | ||
This is not directly a new element, it's just an abstract base class that can be used to register a factory of Nasal-space elements. While that may be considered problematic from a performance standpoint, the idea is to expose the CanvasElement interface to Nasal space, so that developers can more easily prototype new elements in scripting space, and register those with the main Canvas::Group manager | This is not directly a new element, it's just an abstract base class that can be used to register a factory of Nasal-space elements (think elements of a MFD like screens, pages etc). While that may be considered problematic from a performance standpoint, the idea is to expose the CanvasElement interface to Nasal space, so that developers can more easily prototype new elements in scripting space, and register those with the main Canvas::Group manager, without having to be proficient in C++. | ||
Preferably, developers would use inheritance, composition and aggregation to design their elements using | Hopefully, this will allow fgdata developers to come up with features that are reusable and agnostic to the concrete use-case, as well as support independent instances and styling. | ||
The key thing here is that we want to ensure that the Canvas system, and OSG itself, know what an element is all about, without all this knowledge having to exist solely in scripting space. While it may seem ironic at first that moving the implementation of new elements to Nasal, all the internal handling logic would directly use the proper interface of Canvas::element | Which are basically the main challenges Canvas adoption is seeing/causing in fgdata in the last 3 years, i.e. tons of useful features that are highly specific to a single aircraft/use case, without supporting other use-cases, and without being sufficiently flexible and customizable. | ||
Preferably, fgdata developers would use inheritance, composition and aggregation to design their Canvas-based features. However, that point is hard to bring across, and the only Canvas-related features that satisfy these requirements, are native Canvas elements using the Canvas::Element interface. | |||
The key thing here is that we want to ensure that the Canvas system, and OSG itself, know what an element is all about, without all this knowledge having to exist solely in scripting space. | |||
This is also the prerequisite for supporting multi-instance or multiplayer setups where Canvas-specific state may need to be propagated to multiple fgfs instances for replication. | |||
Dealing with Canvas features at the element level is the only sane way of doing so, but is causing quite some traffic for low-level primitives, so that it makes sense to introduce higher level elements for specific use-cases. | |||
While it may seem ironic at first that moving the implementation of new elements to Nasal, all the internal handling logic would directly use the proper interface of Canvas::element | |||
Once new elements have been refined and once they are proven, they could be partially/completely re-implemented in native C++ code, without any of the front-end code having to be changed. | Once new elements have been refined and once they are proven, they could be partially/completely re-implemented in native C++ code, without any of the front-end code having to be changed. | ||
| Line 275: | Line 282: | ||
|description=Stub for exposing Canvas::Element a dedicated Nasal extension point | |description=Stub for exposing Canvas::Element a dedicated Nasal extension point | ||
}} | }} | ||
== CanvasCamera == | == CanvasCamera == | ||