Board index FlightGear Development Canvas

Using a canvas map in the GUI

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.

Re: Using a canvas map in the GUI

Postby Hooray » Sat Sep 22, 2012 8:11 pm

stuart wrote in Sat Sep 22, 2012 7:58 am:Regarding highlighting, I think a better approach will simply be to display an aircraft icon at the appropriate location. That will allow us to indicate runway direction and neatly sidesteps the whole issue of modifying an existing layer. We will want an aircraft layer for the moving map anyway.


With the modified code, this will be fairly simple - for example, adding a new "navaid" layer took me less than 2 minutes now (in this case, I don't manually draw the image, but instead use the NDB symbol from wikimedia commons):
Image
Adding another layer for route manager waypoints would be similarly simple.

That said, there's still some ugly code in it, and we'll want to get rid of it so that the API can really evolve.

For example, while the concept of a "map" and of "layers" is fairly encapsualted now, updating the layer is still done "manually" in a separate callback. This is something where we should really use a MVC based design to update the layer in a decoupled fasion. That would be a huge opportunity to get rid of lots of code and move it to the canvas folder instead.
Also, this will almost certainly be required for dynamic maps.

From a performance/resource usage point of view, it would be great if we could extend the canvas such that:
  • ...it renders groups to textures and merges them on demand
  • ...it differentiates between "dynamic" and "static" map layers (i.e. aircraft/traffic vs. fixed positions)
  • ...it is possible to explicitly configure an update interval in hertz for a map, i.e. in most cases, 0.1-5hz would be sufficient
  • ...groups may refer to an existing group, that would allow us to reuse vector images very easily, without duplicating the data over and over again

I'll try to clean up the code a little and then post it here, so that you can have a look.
Like I said, I didn't bother "fixing/porting" the "runway/parking highlighting" feature properly.

EDIT: https://gitorious.org/fg/fgdata/merge_requests/95
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby stuart » Mon Sep 24, 2012 12:53 pm

Hi Hooray,

As you may have seen from your merge request status, I successfully applied the merge request, but couldn't get it to run last night. I was late and I didn't have time to dig into the reasons why in detail - sorry.

You should be aware that I've added additional function to the dialog to allow listing of airports within 100nm, and displaying the METAR for the selected airport. none of these should affect your re-factoring work, though you'll have to rebase before re-submitting the merge request.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Using a canvas map in the GUI

Postby Hooray » Mon Sep 24, 2012 1:00 pm

Hi, see the merge request - I left a comment there and updated/pushed my changes: https://gitorious.org/fg/fgdata/merge_requests/95
I have already rebased and incorporated your changes.

And yes, I'd like to see this getting reviewed soon, so that we can tease out any issues and commit it, because I have some more drastic changes here, and these things should simplify all related efforts (route manager, mapwidget, navdisplay) - we really shouldn't be adding features to two different code bases.

So far, there are still some ugly corner cases to be found in the new code, but overally it is much more reusable (and efficient) than the original code, as you can see.
I have also added it now to the route-manager and map-canvas dialogs here to further generalize things.

But overall, I'd really prefer if each of us works on a different dialog, so that we can collaborate to improve the backend, that is map.nas
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby zakalawe » Mon Sep 24, 2012 2:13 pm

I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.

Hooray, I have the impression you're also working on the mapwidget / map dialog - but it's all unfinished code? I'd like to avoid repeating effort, so if you're already working on it I can instead give you some help? So far I didn't see how to handle the route-path in the Canvas map, since it requires a path with both ends mapped by geo-coord.

From your screenshot, I'd say some symbol LOD is needed too - the taixways and tower symbols are already meaningless at that zoom-level.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Using a canvas map in the GUI

Postby Hooray » Mon Sep 24, 2012 2:42 pm

zakalawe wrote in Mon Sep 24, 2012 2:13 pm:I did some experimental work on converting the map dialog last night

So did I, and in fact, Tom - see his branch (map-canvas.xml).

I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.

Agreed, we have covered hat here extensively (on the forum and the wiki), because it's a known issue and simple optimization.

Hooray, I have the impression you're also working on the mapwidget / map dialog - but it's all unfinished code?

Depends on your point of view, I have been focused on taking Stuart's original code and optimizing it such that uses layers for different features.
And I wanted to make sure that we don't just stuff tons of Nasal code in XML files, but instead come up with a generic reusable design, that can be used by other dialogs/instruments.

I'd like to avoid repeating effort,

so do I, which is the reason why I previously asked you to wait with your own work, until my changes have been reviewed/merged.

so if you're already working on it I can instead give you some help?

yes, of course - please see the merge request and the TODOs/FIXMEs there - I am well-aware of the current issues, but the point is that I REALLY want to avoid seeing tons of hand-written Nasal code in different dialogs/instruments aircraft.

We need to have a single map.nas module that can be re-used for all GUI/instrument mapping needs.
That's what I have been working on (about 60% there ATM).
I have meanwhile generalized Tom's/Stuart's original code so that it will be easier to use it in different dialogs, without any unnecessary copy/paste going on.


From your screenshot, I'd say some symbol LOD is needed too - the taixways and tower symbols are already meaningless at that zoom-level.

Yes, exactly - please see the merge request and look at the code, we are well aware of the issues, but it was just proof of concept.
The point of the screenshots was that I had ported Stuart's code to use different layers for each feature that can be individually toggled, so that different callbacks can be invoked, and so that the canvas tree for each layer can be lazily created - which makes things MUCH faster when toggling features on/off.
So when I took the screenshot, it was just to demonstrate that it took me 2 minutes to add support for a new navaids layer - or support for showing multiple airports, features that Stuart was planning to add.
That's exactly why I took his code and re-worked it such that it will be more easily extendable, but also more easily re-usable by other dialogs/instruments.

I have now added more MVC-helpers to handle this in a generic fashion.

However, honestly, please only modify the code if you are also interested in improving a single backend, and not tons of custom Nasal code in XML files, which I have been working against recently...

The LOD will be easy to handle once the MVC helpers are fully implemented and adopted.

All that said, I'd love to look at your code too, so that I can check out if I missed anything that we didn't yet cover here.

As a next step, it would be great to review my merge request, so that we can get it re-worked and committed.
Afterwards, we can all use the same code base and improve it for different needs (map widget, navdisplay, route manager).
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby Hooray » Mon Sep 24, 2012 3:57 pm

zakalawe wrote in Mon Sep 24, 2012 2:13 pm:Hooray, I have the impression you're also working on the mapwidget / map dialog - but it's all unfinished code?


Just to be clear about it, I wasn't trying to port the map/mapwidget or navdisplay to canvas, I was just trying to establish the required infrastructure for these efforts - you should keep that in mind when you look at the code.

So when I started this, my primary goals were:
- use different layers/groups for features that can be separately toggled to improve performance (done)
- generalize the code such that there's less embedded Nasal code required in dialog files (half way done, still some ugly special cases in there)
- prepare a design that allows maps to be easily used in both, dialogs and instruments (also about 50% done)
- make it easy to extend the design to support new types of drawables/layers/maps (done)
- use lots of tiny helper functions and hashes instead of huge monolithic "super functions" (80% there)
- come up with optimization opportunities so that the core canvas system can be extended accordingly (been in touch with Tom on that one)
- prepare the design such that it's very easy to support new canvas features, without rewriting tons of code (the MVC work will help here)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby stuart » Mon Sep 24, 2012 5:10 pm

zakalawe, Hooray,

Given that you're both looking at the underlying API, and zakalawe has commit rights to fgdata, I suggest that he's better placed to review and merge Hooray's changes into fgdata than I am.

The only enhancement to the map that I had planned to add was to swap the highlighting code for a simple plane icon in the correct place, and hiding the parking positions at low zoom. I suspect both of these are also of interest for the map widget, so I suggest I bow out of this and concentrate on the Select Airport dialog. Too many cooks :)

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Using a canvas map in the GUI

Postby Hooray » Mon Sep 24, 2012 5:46 pm

Fair enough, that's what I was suggesting: each of us works on a different dialog/instrument, but that all of us stop adding tons of Nasal code to the XML dialogs:

Yes, we can start implementing each use case indidually in separate files, with lots of Nasal code embedded in dialog xml files and instruments, but I really don't believe that's a good idea. We want to increase code sharing and reuse here.

Features implemented like this cannot be easily reused, - just look at what Stuart (no offense!) has done with Tom's map demo: he didn't generalize anything at all - he just copied/pasted it, and started customizing it afterwards (heavily). And that even though he's a core developer and pretty familiar with Nasal ;-)

Now if everybody starts doing that, we'll end up with various dialogs and features more or less complete, but completely inconsistent, with no code sharing. But we won't be able to establish a re-usable and generic design.

Yes, coming up with such a re-usable design is more complicated and more time-consuming, but it's the right thing to do, also from a maintenance point of view. Just imagine some core changes, or changes in the canvas Nasal module: Once we have a single component, we can easily address those issues, but we cannot fix tons of separately implemented "map"-like dialogs and/or instruments manually.

Seriously, I found it very intimidating when I looked at the amount of code in the airports.xml file - and that is even though I do know Nasal :-)

We really don't want people creating "copy/paste" derivates and customizing those manually.
Really, we can create a re-usable design just by going through a handful of iterations, and that's what I have been doing during the last couple of days.

We only need to ask ourselves a handful of questions:

- what is needed to reduce the amount of Nasal in dialog XML files?
- what is needed to make this more reusable for use in other dialogs?
- what is needed to make this reusable in instruments?

Admittedly, I did introduce a handful of issues and also ugly code - but that's largely out of "laziness", because I didn't want to completely rewrite the code that Tom and Stuart had written, that's why I am using less OOP than I want, so I needed to add wrappers to re-use that code.

But I am really confident that we can easily address those 3-5 issues (2 are sorted already) during the next days - in the long run, we'll end up with a single, highly customizable, component that can be used for all purposes, which can be easily maintained, too.
Last edited by Hooray on Mon Sep 24, 2012 8:58 pm, edited 1 time 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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby stuart » Mon Sep 24, 2012 8:11 pm

Hooray wrote in Mon Sep 24, 2012 5:46 pm:just look at what Stuart (no offense!) has done with Tom's map demo: he didn't generalize anything at all - he just copied/pasted it, and started customizing it afterwards (heavily). And that even though he's a core developer and pretty familiar with Nasal ;-)


You are preaching to the choir here. I was quite aware of what I was doing - my aim being to see what was possible and refactor later once I'd worked out how things should work.

In passing I should point out that both zakalawe and I are professional software developers, with degrees in Computer Science. As it happens we were in the same year at Edinburgh Uni. So, we're fairly au-fait with how to design software properly. Don't mistake prototyping and hacking around for not being aware of architectural issues, or able to address them. There's no need to lecture us on the benefits of generalizatio or libraries of re-usable code :).

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Using a canvas map in the GUI

Postby Hooray » Mon Sep 24, 2012 8:34 pm

I wasn't lecturing you at all. I absolutely believe that you understand the benefits of generalizing code. The point is however, that NOT generalizing code, i.e. "hacking around" is MUCH easier than doing the right thing, like you said here:
stuart wrote:don't mistake prototyping and hacking around for not being aware of architectural issues, or able to address them.


I certainly don't - but let's face it: It will take all of us MUCH less time to just focus on a specific use-case, i.e. one dialog and/or instrument, but we won't be able to re-use what others have done that way.

There's no need to lecture us on the benefits of generalizatio or libraries of re-usable code

Please don't take that personally - but just look at the degree (lack) of generalization that we've seen in the base package since mfranz stopped maintaining the Nasal code. Or look at most XML dialogs that contain embedded Nasal code: more often than not, they were just copied/pasted together, because nobody cared enough to generalize things and move general purpose helpers to the gui.nas module.

In other words, I wasn't lecturing anybody, I was merely suggesting that this very "copy/paste & hack around" practice be stopped in this particular case - so that I can provide a generic re-usable module, if nobody else is sufficiently interested to do that. :D

Obviously, I would then appreciate not having to merge in tons of custom-written copy&paste "hacks". ;-)

Right now, it will take us only 2-3 more use cases to generalize the map.nas module such that it can be easily re-used for most GUI cases, and maybe another 2-3 cases for instruments. So maybe, we are talking about a handful of design iterations here - which may take another 2-3 weeks (weekends).

my aim being to see what was possible and refactor later once I'd worked out how things should work.

My own refactoring work also started out as "hacking" around, when I tried to optimize your implementation - and there's still lots of code, that I want to get rid of... but at least, there's a plan to establish a shared component.

Seriously, it's great to see that we technically agree on what needs to be done - but it would be truly hilarious if we could work out a way to make that happen :P
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby TheTom » Mon Sep 24, 2012 9:40 pm

zakalawe wrote in Mon Sep 24, 2012 2:13 pm:I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.


I'm thinking about using a separate canvas for each symbol so that every instance of it is just a textured quad. For efficiency reasons it would be good to draw all symbols to a single canvas/texture and put all quads into a single node. So probably I'll add a new element type for putting quads into a single element which are all rendered at once. Maybe we can even use a geometry shader to just copy the positions to the GPU and generate the full quads with the shader. Ideas and suggestions are always welcome :)

zakalawe wrote in Mon Sep 24, 2012 2:13 pm:So far I didn't see how to handle the route-path in the Canvas map, since it requires a path with both ends mapped by geo-coord.

If you use Path.setDataGeo() all coordinates are mapped.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Using a canvas map in the GUI

Postby stuart » Tue Sep 25, 2012 9:30 am

Hi Hooray,

I think we're talking at cross-purposes here. You seem to be under the impression that no-one else is interested in generalizing the map code. That's absolutely not the case. everyone on this thread want to make the code re-usable, and if you hadn't done your refactoring I (or more than likely James) would have in the near future when migrating the moving map.

Seriously, it's great to see that we technically agree on what needs to be done - but it would be truly hilarious if we could work out a way to make that happen :P


As noted above I've suggested that James looks at merging your code, as he's wanting to update the moving map code and I'm sure has some ideas himself. I'll hold off making any further changes until this is done to avoid the merge problems (hence my reference to "too many cooks").

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Using a canvas map in the GUI

Postby Hooray » Tue Sep 25, 2012 10:52 am

I'll hold off any further work on this until we agree that this is how we want to proceed then. This really isn't meant to sound negative, but obviously, I also, hate the idea that I have wasted my time working on this during the last weekend....

Status: Last thing I worked on was adding a real "Layer" class that is mapped to canvas.Groups - and getting rid of the non-ported code, namely, the "init" method (which was also just copied/pasted together based on the original code) - and replacing that with a "data provider" abstraction so that layers can be populated by "provider" classes with a well-defined interface.
That should make it possible to add support for new layers, just by deriving from a "Layer" class an implementing its interface so that the "model" is properly populated.

Once that is working, most of the really ugly code is gone, but we would still need to look at implementing the "controller" part properly, for this I have currently added two stubs: "TimeBasedController" - for layers that are populated by running a settimer() based callback (one or more), and "ListenerBasedController" for layers that will be populated by invoking a listener (one or more) - which would be the case for the airport-selection dialog, i.e. registering a listener for the "selected-airport/id" property so that the model and view are updated by the controller then.

In addition, I have prepared a "HybridController" which supports both, timers and listeners, to update its model/view.

Note that while the patch/merge request may look a little inconsistent, it already removes most specialized code from the actual dialog XML file - i.e. it's much more configurable, and it actually moves map instantiation/parametrization to XML space. I have also started reusing the code in the route manager dialog to ensure that the abstraction is more agnostic to the type of dialog.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Using a canvas map in the GUI

Postby zakalawe » Tue Sep 25, 2012 11:26 am

TheTom wrote in Mon Sep 24, 2012 9:40 pm:I'm thinking about using a separate canvas for each symbol so that every instance of it is just a textured quad. For efficiency reasons it would be good to draw all symbols to a single canvas/texture and put all quads into a single node. So probably I'll add a new element type for putting quads into a single element which are all rendered at once. Maybe we can even use a geometry shader to just copy the positions to the GPU and generate the full quads with the shader. Ideas and suggestions are always welcome :)


Hmm - that's possible. The issue there (at least based on the NavDisplay) is that there's quite high variance in the symbols, e.g. colour changes. For the ND I keep the symbols at greyscale, and colour them based on parameter data (active vs tuned vs inactive for navaids, for example)

Definitely needs some thought, but I think it can be an upgrade - we don't need to get the design right immediately! I do like the idea of the Canvas managing the symbol cache texture, however, since generating it by hand (as the TCAS and ND currently require) is annoying.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Using a canvas map in the GUI

Postby zakalawe » Tue Sep 25, 2012 11:29 am

Hooray, Stuart: I'm going to review the merge request today/tomorrow. Be aware, for this kind of thing, I'd much rather iterate rapidly than try to get the correct design at once. So I'm okay with some short-term duplication / copy-and-paste ugly design, while we all learn what the Canvas can do, and where it needs further works. There's no point making the code beautiful until we're sure it's staying :)
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests