Board index FlightGear Development Canvas

Adding a canvas to the route manager dialog (split)

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.

Adding a canvas to the route manager dialog (split)

Postby Hooray » Wed Sep 19, 2012 2:14 pm

Also, it would probably be pretty simple to also add a canvas region to the route manager dialog, so that waypoints and airports are shown there too:
Image

zakalawe wrote in Wed Sep 19, 2012 1:26 pm:But it's simply a list of lat,lon pairs so exposing it is really trivial - will get it done in the next few days. The Navcache changes are also in now, so papillion and I will look at porting the ground-radar to the canvas, and supporting the v860 pavement / taxiway primitives in the future.


Like you say, many of these changes will boil down to exposing fairly simple positional information of having lat/lon points,or vectors of lat/lon points.
So, the C++ machinery to expose this info to Nasal could probably be shared, i.e. 1-3 C++ templates, even for different tuples of doubles.

Looking at Stuart's screen shot, it would obviously be great to also get access to some basic landclass information, i.e. the underlying vector information, so that terrain and water can be rendered differently by the canvas system. This is something that would be a HUGE hack in Nasal space if done via geodinfo().
But adding a new extension function to query the tile manager to get vector data would not be as computationally heavy.
Last edited by Hooray on Thu Sep 20, 2012 10:59 am, edited 2 times in total.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Using a canvas map in the GUI

Postby zakalawe » Wed Sep 19, 2012 5:42 pm

This is in next now, sample code:
Code: Select all
var fp = flightplan();
for (var i=0; i<fp.getPlanSize(); i += 1)
{
  var leg = fp.getWP(i);
  debug.dump(leg.path());
}

I'll be looking at adapting the MapWidget now, which will probably involve symbol / icon support in the Canvas map, since that's a recurring feature of all these displays.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Using a canvas map in the GUI

Postby Hooray » Wed Sep 19, 2012 6:30 pm

That's great news. With these changes in place, it should already be possible to directly show a SVG image for each waypoint and connect them using OpenVG paths, even without separate "icon" support.

That said, if you are set on using raster images for the icons, I'd suggest to get in touch with Tom and coordinate things a little (if you haven't already).

We've exchanged a fair amount of info regarding image caching, so that repeatedly used resources (vector images or raster images) would be loaded just once and get referenced otherwise (i.e. cached). I know this is natively supported by OSG's image cache.
But at the moment, this would need to be explicitly handled at the design level by using nested canvases, to reduce unnecessary resource usage.

However, some form of "caching support" will probably still be required at the core canvas level once the canvas is adopted for "full" GUI drawing, because then, we'll usually be dealing with lots of identical/shared vector image and raster image data, i.e. repeatedly instantiated widgets should largely be able to share most vector/raster data in the property tree. And there should be a performance benefit when keeping such widgets "in memory" (i.e. in the tree) and just parametrize them on demand.

Regarding the flightplan() API ( I didn't yet look at the C++ code), I'd suggest to keep real CDUs in mind, which usually support at least two flight plans, i.e. "active" and "inactive" - which can be swapped easily. In other words, supporting an optional index number and defaulting it to 0 (i.e. first flight plan) would keep this pretty flexible, so that future instruments/dialogs could handle multiple flight plans, without it necessarily having to be the active plan - which would also be a useful route manager addition.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Using a canvas map in the GUI

Postby zakalawe » Thu Sep 20, 2012 10:15 am

Hooray wrote in Wed Sep 19, 2012 6:30 pm:Regarding the flightplan() API ( I didn't yet look at the C++ code), I'd suggest to keep real CDUs in mind, which usually support at least two flight plans, i.e. "active" and "inactive" - which can be swapped easily. In other words, supporting an optional index number and defaulting it to 0 (i.e. first flight plan) would keep this pretty flexible, so that future instruments/dialogs could handle multiple flight plans, without it necessarily having to be the active plan - which would also be a useful route manager addition.


Already done - flightplan() takes a file path argument, which can be used to store inactive flight plans, or additional FMS 'slots'. It would also be trivial to extend the route-manager to actually keep a second flightgear::FlightPlan* instance (and expose its properties) as the 'inactive plan' - the code was explicitly written to support that - nothing assumes there's only one flightplan.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac


Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests