Canvas MapStructure: Difference between revisions

{{Canvas Navigation}}

[[File:Gpsmap196-MapStructure-with-styling-applied.png|thumb|MapStructure layers integrated in GPSMap196 with some custom styling applied]]

[[File:VSD-prototype-by-omega95.png|thumb|Canvas-based VSD prototype (Vertical Situation Display) developed by Omega95]]

Thus, the idea was to grow a library of generic building blocks that live in $FG_ROOT and that are sufficiently generic and customizable to basically enable people to collaborate more properly by providing a strong incentive via compelling functionality that can be easily maintained/updated in the future. The thinking was that all aircraft/GUI dialogs using a single back-end would automatically benefit from significant updates to the back-end that way (think performance, features etc).

Our strategy was to adopt a MVC (model/view/controller) approach, where the model would represent what is to be rendered, the view would map the Canvas system and its primitives (elements) and underlying APIs, whereas the controller would usually be use-case specific (think cockpit vs. GUI dialog).<ref>{{cite web

   |title  =  <nowiki> my "2c" ;-) </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

== Performance Considerations ==

Recently, it has been two years since [[Canvas]], our 2D rendering API, got integrated. And even today, there are people claiming that aircraft using Nasal and Canvas are generally slow and don't provide sufficient performance, suggesting not to adopt Canvas yet, so here are some comments about that, to help put some context around such statements:

That is exactly why people are working towards more targeted frameworks on top of Nasal/Canvas - but it's a process that is very much still in progress, and probably will be for at least another 2-3 release cycles. Pointing out obvious shortcomings isn't going to help anyone though - certainly not as much as getting involved in one way or another</nowiki>

     |title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki>

     |author=<nowiki>Hooray</nowiki>

<br/>

The other thing is that translation (centered/off center mode) should always be based on the parent group's dimensions (bounding box) and that we really shouldn't be using the top-level canvas, because a MFD very well be split into several screen areas (which also applies to the GPSMap196 and most other modern avionics).

     |title=<nowiki>Evolving the MapStructure & NavDisplay Frameworks ...</nowiki>

     |author=<nowiki>Hooray</nowiki>

We're talking here about roughly 50 lines of C++ code, which exist already and which would need to be turned into a Canvas::Map::Projection

Note that this would benefit any, and all, Canvas-based NavDisplay/Map applications, too - also note that this information is readily available in various places, so there is no need to draw any wrong conclusions or spread any misinformation here.<ref>{{cite web

   |title  =  <nowiki> Re: Any plans for a new GUI? </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

   |We've already fixed that in the (old) map dialog, by using an azimuthal equidistant projection (see [[images/7/71/Map_north_pole_route.jpg|screenshot]]). Porting the projection to Canvas is on my todo list. Such a projection is much much better for navigational use.

Curves in routes are not calculated by Canvas, nor by the ND though. It's the route manager that splits up a route in segments in order to get smooth transitions.

     |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki>

     |author=<nowiki>Gijs</nowiki>

{{FGCquote

   |The new ND uses the actual route-manager paths, which allows it to draw holdings, flyby waypoints (thanks to James recent work) etc. But we'll need the azimuthal projection anyway, so I'll bump my todo list

     |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki>

     |author=<nowiki>Gijs</nowiki>

<br/>

Ideally, we would expose the projection as a property for each Map so that it can be changed dynamically.

     |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki>

     |author=<nowiki>Hooray</nowiki>

{{FGCquote

   |is anyone working on replacing the map dialog based upon this code? Because that seems like the most important use case to demonstrate that MVC pattern can support, aside from the NavDisplays.

     |title=<nowiki>Re: How to display Airport Chart?</nowiki>

     |author=<nowiki>zakalawe</nowiki>

</ol>

     |title=<nowiki>Re: Phasing out MapWidget post 3.2</nowiki>

     |author=<nowiki>onox</nowiki>

   |the recent GUI work committed by TheTom means that we can phase out the PUI map-canvas.xml dialog and create the whole dialog procedurally using a native canvas window, because we really only need two types of widgets: buttons and checkboxes, which are both supported now, thanks to the new "Aircraft Center":

[[File:MapStructure-based Weather Editor Widget for Canvas using interactive and editable lcontroller files.png|500px|thumb|This screen shot shows an experimental MapStructure-based Weather Editor Widget for [[Canvas]] using interactive and editable lcontroller files that respond to GUI events so that map symbols can be interactively placed on a map.]]

     |title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>

     |author=<nowiki>Hooray</nowiki>

{{FGCquote

   |The rationale being that we're in the process of turning our map-canvas.xml dialog into a generic, and reusable, widget for $FG_ROOT/Nasal/canvas/gui/widgets - the widget is using the new Layout engine to align other widgets (checkboxes &amp; buttons for now). And one of our goals is to also modernize airports.xml (the airport selection dialog) such that it can use MapStructure. The simplest way would be to simply turn the PUI CanvasWidget into a Canvas.Window() so that layouting etc works as expected, and so that we can simply show the new scripted MapWidget there.

     |title=<nowiki>Using a PUI CanvasWidget as a Canvas.Window ?</nowiki>

     |author=<nowiki>Hooray</nowiki>

</ul>

     |title=<nowiki>Re: 777 EFB: initial feedback</nowiki>

     |author=<nowiki>Hooray</nowiki>

=== Framework ===

* we should add some helper functions for people to more easily do RAD when developing new layers/controllers, this would include supporting reloading from disk, and creating a simple canvas window to show the corresponding layers, maybe with a "reload" button that suspends and restarts everything after reloading - this would probably even help us {{Not done}}

* logging should probably be handled by the framework directly, so that messages can be redirected or stored {{Not done}}

* support benchmarking/profiling of layers via systime() - as mentioned by Philosopher on the forum {{Not done}}

Caching is accomplished by a little helper framework called '''SymbolCache''' which sets up an empty Canvas texture for storing required symbols there.  

This is where symbols for VORs, DMEs, FIXes and waypoints will be kept.  

Internally, each *.symbol file will still contain all the logic required to actually render the corresponding symbol, which may include  hard-coded OpenVG drawing commands, but also SVG or raster images.  

However, the cache will be dynamically populated according to all the symbols that are required for each layer. This approach proved quite efficient and straightforward so that even the extra500 developers adopted this method on their [[Avidyne Entegra R9]] instrument.  

-->

<br/>

Setting _equals to a "return 0" function simply means that each object will be taken off and recreated on each search. But, when there's a better id to use, MapStructure can remove only the old ones and add only the new ones. How that is done depends on both the model object and the drawing – for instance, if a *.symbol file says to completely redraw the Canvas group based on the model, that means it potentially could be used with different models during its lifetime, whereas if the symbol is only set up once on initialization, it would not reflect changes in it's model object and thus should be removed when it is gone.

     |title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki>

     |author=<nowiki>Philosopher</nowiki>

{{FGCquote

   |The other ugly thing about _equals is that it's essentially duplicated by MapStructure {{gitorious source|fg|fgdata|commit=fcf18d70e20ef629d96367cd0907dae6178e1997|path=Nasal/canvas/MapStructure.nas|line=516|text=here}}, and is used {{gitorious source|fg|fgdata|commit=fcf18d70e20ef629d96367cd0907dae6178e1997|path=Nasal/canvas/MapStructure.nas|line=894|text=here}} to find models inside of the Layer's internal list, while the geo search obviously uses a competing approach. I might get around to fixing that ;). Basically MapStructure's whole flow is: layer searchCmd -&gt; models -&gt; symbols -&gt; canvas drawings.

     |title=<nowiki>Re: Get objects to show up on Map/Radar</nowiki>

     |author=<nowiki>Philosopher</nowiki>

{{FGCquote

   |The main thing to keep in mind here is that many MapStructure layers deal with positioned objects, i.e. objects that have lat/lon/altitude - internally, the system uses a "diff" (delta) method to compare the current result set against the previous result set to tell how many new/removed items are there - so that things can be selectived updated (added/removed), i.e. to only partially redraw/update things for the sake of efficiency.

     |title=<nowiki>Re: Live WXRadar MapStructure Layer Development</nowiki>

     |author=<nowiki>Hooray</nowiki>

For a list of MapStructure files (meanwhile incomplete), see: [[Canvas MapStructure Layers]]

Once you have found a layer that is not yet style-able, you need to encode style-able attributes using the relevant_keys vector.<ref>{{cite web

   |title  =  <nowiki> Re: [SOLVED] How to modify symbols in MapStructure layers </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

some layers are still missing styling-support - which basically means identifying everything that is currently hard-coded but styling related (think colors, fonts, sie, images/artwork) and replacing that with a variable, the same variable should be added to the df_style (default style) of the symbol, and then you need to set up a cache entry specifiying the symbol specific variables (e.g. color and fontsize), so that the styleable-cache can tell if it has a certain variant of a symbol or not

map-canvas.xml is a simple example, artix's Airbus style is more sophisticated.<ref>{{cite web

   |title  =  <nowiki> Re: [SOLVED] How to modify symbols in MapStructure layers </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

For example, open the VOR.symbol file and see how it sets up a default style hash (df_style) here: https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Nasal/canvas/map/VOR.symbol<ref>{{cite web

   |title  =  <nowiki> Re: [SOLVED] How to modify symbols in MapStructure layers </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

<ref>{{cite web

   |title  =  <nowiki> Re: [SOLVED] How to modify symbols in MapStructure layers </nowiki>  

   |author =  <nowiki> Hooray </nowiki>  

{{MapStructure lcontroller|layername=TUT}}

<syntaxhighlight lang="nasal">