Board index FlightGear Development Canvas

NasalElement vs. CanvasMgr::elementCreated

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

NasalElement vs. CanvasMgr::elementCreated

Postby Hooray » Mon May 12, 2014 3:39 pm

what is the recommended way to register new elements at runtime ?

I can see that sc::Element is already exposed to Nasal via NasalCanvas.cxx - I have added another _newCanvasElement() member to the canvas namespace, and looking to add a method to expose the std::map with group elements so that new groups can be added.

The main idea here is that I want to be able to extend the core canvas system by allowing custom elements to be prototyped & registered via Nasal (analogous to addcommand() ).
According to CanvasMgr this seems to be supported already to some extent ?

Note that I don't think that we need many Nasal-driven elements - the motivation is really just to provide a mechanism so that new building blocks can be directly registered as new elements, which may initially be prototyped in scripting space, i.e. by the MapStructure/ND folks. I am primarily thinking in terms of things like our SymbolCache for now, which would seem like a sure candidate for being re-implemented in C++ at some point.

This would mean that we can prototype new element types, and if/when those are optimized through C++ additions, any back-end code will automatically benefit from such optimizations, without having to be ported, because it already was a proper CanvasElement previously.

For starters, this may involve a simple Nasal-driven element for handling things like 1) styling & animations, 2) terrain height maps or even 3) ESRI shape files.

Currently, we are implementing animations by using timers and listeners - in the long run, we may want to use SGCondition/SGStateMachine or even some of the AP/PID components to reduce Nasal overhead - thus, exposing a dedicated wrapper means encapsulating things, so that we only have to update a single place then.

We could prototype such things in Nasal and if we find things being too slow, we can trivially update stuff. Another good candidate may be having elements that support implicit caching by writing canvas textures to a SQLite DB in $FG_HOME, as discussed previously: viewtopic.php?f=71&t=22082&p=209116&hilit=sqlite#p209116

If we could extend the Canvas system at runtime from scripting space by implementing Canvas::Element and registering those Nasal classes, we would ensure that things can be easily optimized in the future.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11977
Joined: Tue Mar 25, 2008 8:40 am

Re: NasalElement vs. CanvasMgr::elementCreated

Postby Hooray » Mon Jun 02, 2014 4:40 pm

I have this basically working here - the main motivation is that we want to provide some more "structure" for people creating canvas-based features like the pfd, nd, efb, HUD, cdu etc - but also MapStructure/Avidyne stuff. As long as new displays/instruments can be registered as higher-level canvas elements, we would ensure that some form of encapsulation is enforced, i.e. so that multiple instances can be trivially supported, and I/O really just takes places via the property tree. People would need to declare properties that they read/write through custom attributes, which would make it straightforward to support distributed setups for any canvas-based textures, including multiplayer, but also multi-instance setups like those at FSWeekend.

I am basically thinking of turning important building blocks into NasalCanvasElements and allowing those to be registered, so that any canvas can use such elements, i.e. to implement support for animations, caching.

The idea is to establish boundaries and interfacing mechanisms, so that things can be easily optimized/re-implemented or replaced once the need arises, without us having to touch a ton of places.
For example, a simple "animation" element would accept a handful of property events and internally manage timers and listeners - if that shows up as a bottleneck at some point, it can be optimized or re-implemented through native C++ code, without having to change the front-end code.

Likewise, our current "SymbolCache" could be registered as a custom NasalCanvasElement, and easily re-implemented in C++ at some point.
MFDs are another good example, because page/mode management is one of the most common requirements here, which is explicitly implemented using fairly ugly Nasal code at the moment, but can be trivially expressed through supporting a custom "MFD" element with "page" children (basically groups).

I am about to prototype a simple demo that exposes individual MapStructure layers as a custom Canvas::Element named "managed-map", which internally supports navaid layers directly (ndb, vor, dme etc)

The long-term idea is to establish sufficient encapsulation, so that we can also support recursion, and use the whole thing in stand-alone mode, e.g. something like FGCanvas, without being extremely specific to a single aircraft/instrument.

I think this could be a worthwhile direction to explore in the long-term, and will post some updates/screen shots over time...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11977
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests