Board index FlightGear Development Canvas

Shuttle 2D drawing helpers / G1000 effort ?

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.

Shuttle 2D drawing helpers / G1000 effort ?

Postby Hooray » Sun Oct 15, 2017 12:30 pm

https://sourceforge.net/p/flightgear/ma ... /35611240/
Thorsten wrote:By now I have a library of procedural commands which allows you to e.g.
draw a HUD with a minimal set of commands and re-draw it with a different
design if you find it doesn't match reality runtime - something which SVG
can just not do.

All it needs is to streamline it and document it, and then the situation
your describe may (or not) change, but in my opinion it beats SVG in
designer-friendliness by a large margin - simply because you can change
spacings etc. runtime in FG. Whereas re-drawing a pitch ladder with
different spacing in SVG is a piece of work and there's no guarantee you
get it right runtime.
James wrote:Indeed, it sounds as if, within the Shuttle code, you have developed a considerably superior version of the Canvas API, would it not make sense to move that into the FGData Canvas files, and standardise it? It sounds as if Dirk and probably many other people want exactly that kind of functionality. What I don’t understand is why, given such a rich API, it would make sense to use manually crafted SVG as the starting point.


Thorsten, were you referring to the canvas_draw.nas file in the shuttle repository ?
If so, would that be something that you'd consider adding to $FG_ROOT/Nasal/canvas ?

I am thinking primarily in terms of efforts like the G1000 and other MFDs where it may indeed be handy to have a library for procedurally creating elements - like you mentioned elsewhere, I am also more likely to create SVG/XML using a text editor than using Inkscape, but if we had a library for doing this sort of stuff procedurally, that could indeed be a game changer - and I suppose, that would also apply to Stuart ?

I am thinking in terms of low-level helpers for "shapes", and higher level helpers for common elements (altitude ladder, speed tapes, artificial horizon).

The reasoning being that we are seeing more and more aircraft/cockpit duplicating stuff unnecessarily, and the whole reason for creating the Canvas system was indeed to come up with a 2D drawing API ...

Ideas, thoughts ?
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: Shuttle 2D drawing helpers / G1000 effort ?

Postby Thorsten » Sun Oct 15, 2017 12:43 pm

If so, would that be something that you'd consider adding to $FG_ROOT/Nasal/canvas ?


Sure, but as usual it should be tidied up before use (which it shares with other things on a waiting list to arrive at FGData, such as the display effect).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Shuttle 2D drawing helpers / G1000 effort ?

Postby Hooray » Sun Oct 15, 2017 4:21 pm

Okay, then my suggestion would be to put stuff that is intended to eventually become "generic" into a dedicated "canvas_draw_shapes.nas" file, or something along those lines. Maybe using a canvas sub-folder, so that such library code can be moved there over time, with the clear understanding what ends up there is intended to make it back into fgdata at some point in the future.

From a canvas standpoint, we may end up with a shape-drawing library, and a higher-level library leveraging that to draw actual HUD/MFD elements.

My thinking here is that it would be good to establish this separation as early as possible, without meaning that any of this has to end up in fgdata soon - but rather to make sure that the higher level modules really only end up using these files, which would then be serving as the "interface". The point being that this makes it much easier to benchmark/profile and stress-test these lower-level "workhorses", but also to optimize them in Nasal space or through C++ hooks, without having to touch any of the higher level modules leveraging these modules.

To some extent this is overlapping with motivation to create the MapStructure MVC work, while we fully realized that it would be far from perfect, and that we'd have more ideas than spare time to implement everything - it is now relatively straightforward to actually benchmark/profile and stress-test or optimize these layers, even if that were to mean re-implementing parts in C++, without having to touch any of the higher level modules actually using those modules (think NavDisplay or the map-canvas.xml and airports.xml dialogs).

Equally, it would be pretty straightforward to render a Canvas GUI dialog that calls all functions in the file to render each symbol to the Canvas - i.e. for regression testing purposes, I mention that, because the comments quoted above were made in the context of the back-then broken SVG parser. And since there are plans being discussed to replace the SVG parser and/or the ShivaVG-openVG implementation via Skia, that may be a worthwhile thing to keep in mind ?
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: Shuttle 2D drawing helpers / G1000 effort ?

Postby Thorsten » Sun Oct 15, 2017 5:26 pm

Okay, then my suggestion would be to put stuff that is intended to eventually become "generic" into a dedicated "canvas_draw_shapes.nas" file


I even almost got the name right it seems...

https://sourceforge.net/p/fgspaceshuttl ... s_draw.nas
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Shuttle 2D drawing helpers / G1000 effort ?

Postby Hooray » Sun Oct 15, 2017 6:05 pm

Actually, I noticed the name you were using - the point was not the exact name that I suggested, but rather the separation between the 2D drawing helpers and the ADI ball stuff in there, which is why I suggested to add a separate canvas sub-folder and put stuff there that is intended to make it back upstream "over time". That way, it would also be easier to look at the code without having to familiar with the shuttle and any of its Nasal modules.

Sorry for the misconception, I don't care what name you end up using - I really only meant to suggest that we keep this distinct from unrelated functionality that is not intended to be merged with fgdata/Nasal, and in the meantime use a separate folder for such stuff - you can use io.include() to still load such files explicitly.
Last edited by Hooray on Sun Oct 15, 2017 6:14 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: Shuttle 2D drawing helpers / G1000 effort ?

Postby Thorsten » Sun Oct 15, 2017 6:10 pm

The ADI ball is just another procedural element being produced in there - the most complicated one by some margin, granted, but no different from a pitch ladder in concept (if you need a 2d ADI ball, you can just call the routine once and use translations).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Shuttle 2D drawing helpers / G1000 effort ?

Postby Hooray » Sun Oct 15, 2017 6:25 pm

since you mention performance - have you checked how often the lower level helpers get called by the ADI ball ?
I am wondering, because your code is rather explicit/read-able, whereas you usually tend to write concise code and favor performance over readability - referring to creating 3 vectors and appending them one-by-one as opposed to appending a single vector using a single append() call.
This is not a suggestion to change things, but merely intriguing, because you mentioned how the ADI ball would be a major resource hog, so I would have assumed that you were using "less-readable" code ;-)

Or is this stuff never called more than once ?

Anyway, given the current structure of your code it would even be possible to compile() the code only once and use another func to make sure that the readable version is never called more than once, because from a performance standpoint, all you may ever need is creating the vector once - thus, instead of returning the vector, you could return a func returning the vector:

Code: Select all
return func shape_data;


The caller would thus obtain a function to retrieve the shape_data - which should be cheaper than invoking the shape API more than once, but still more expensive than storing a Nasal handle to the variable once.
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: Shuttle 2D drawing helpers / G1000 effort ?

Postby Thorsten » Sun Oct 15, 2017 6:39 pm

From a performance POV, calculating the ADI ball as done in the canvas_draw.nas code is a negligible (immeasurable) fraction the cost of the props.nas / setprop/ whatever technique to actually pass it to canvas to be rendered - so there's no point in optimizing this part.

(I've stated the relevant observation a few times, last time not so long ago on the mailing list.)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Shuttle 2D drawing helpers / G1000 effort ?

Postby Hooray » Tue Oct 17, 2017 8:04 pm

I realize that the ADI ball is a little special, but if there are any other use-cases (2D) where performance is suffering from the property tree throughput, it would be possible to provide a Nasal-level API to bypass the property tree, this is done in a few places for which there is no property mapping at all, i.e. it would be possible to directly call C++ code once and pass arbitrary Nasal data structures C++<-> Nasal
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


Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests