Board index FlightGear Development Canvas

Plot2D and graph helpers

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: Plot2D and graph helpers

Postby clm76 » Fri Mar 09, 2018 8:14 am

Hi,
Some problems with the new version of the oscilloscope :
- The number « 1 » (initialization) is staying when changing the values (screenshot 1).
- Number format problem in certain cases (screenshot 2).
- Traces are not displayed on the screen  : trace 1 = autopilot/internal/course-offset (value 13), trace 2 = autopilot/internal/nav1-course-error (value 18)

Image
Image
clm76
 
Posts: 149
Joined: Tue Oct 30, 2012 8:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2018.3.0
OS: Linux Mint 18.3

Re: Plot2D and graph helpers

Postby Thorsten » Fri Mar 09, 2018 8:53 am

I've improved the skinnable's code to make it more general and manage the events.
The new code is here and is documentated in the wiki.


Okay, all looking good to me - where do we want them?

Nasal/canvas/plot_helpers/ so that they can be io_include()d when needed?
Thorsten
 
Posts: 10729
Joined: Mon Nov 02, 2009 8:33 am

Re: Plot2D and graph helpers

Postby Hooray » Fri Mar 09, 2018 2:42 pm

I don't have any preference/suggestion here other than getting in touch with TheTom - primarily, because our existing Canvas APIs are intended to be directly available, i.e. people don't have to include stuff explicitly. I am aware of GC/memory footprint considerations - but would nevertheless expect such APIs to be always available - in other words, including such modules separately may also not be in the interest of the end-user from a GC standpoint.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby Thorsten » Fri Mar 09, 2018 4:07 pm

in other words, including such modules separately may also not be in the interest of the end-user from a GC standpoint.


...whereas including stuff by default but not using it will be unpopular with the core developers.

So the question is - given that this is a partially redundant approach (my cdlg_widgets also contain clickspots and can be used for skinning) - is there any benefit in having these 'always on'?
Thorsten
 
Posts: 10729
Joined: Mon Nov 02, 2009 8:33 am

Re: Plot2D and graph helpers

Postby Hooray » Fri Mar 09, 2018 6:51 pm

none of this would be "running" - it's just APIs, i.e. a few hundred symbols/references more

to be fair, the whole scripting-based canvas namespace is already being loaded via a so called "Nasal submodule" (based on ThorstenB's work) - IIRC, Tom adopted that in response to core developer feedback expressed on the devel list - originally, it was a conventional Nasal module in $FG_ROOT

In theory, this makes it possible to disable the Canvas modules - even though I am pretty sure that this hasn't received much attention/testing recently.

From a technical standpoint, I believe that Canvas related UI stuff would belong to the Canvas GUI module, and could also be loaded/unloaded that way.
Obviously, there is a certain grey area when it comes to modules that may also be used by non-UI work, e.g. 2D plotting on an MFD/instrument.

I do agree that core developers are likely to request Canvas APIs to be made available in an opt-in fashion, i.e. on demand.
Realistically, that's already the fact by putting stuff into the canvas namespace/module

In a way, this is not specific to this particular effort - the FG1000 also depends on certain Canvas APIs that were later (at a time when TheTom was not around), e.g. the MapStructure stuff, and we ended up loading the map APIs "always", under the assumption that such modules would not be aircraft specific, and could also be used by the UI system (which is the case).

And Stuart's FG1000 supports both use-cases, too

Equally, the Canvas/MapStructure SymbolCache texture (canvas) is currently created and populated by default, too - you can find it in every running fgfs instance by navigating the canvas tree using the property tree browser

http://wiki.flightgear.org/Canvas_MapSt ... ymbolCache
Image

We didn't have any well-established dependency management framework for Nasal at the time, and the addon framework also is a fairly recent development.
Thus, it would have been quite a stretch to load stuff on demand (and difficult to manage properly), i.e. premature micro-optimization that would have only provided marginal benefits
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby rleibner » Fri Mar 09, 2018 8:05 pm

Although I understand both points of view, I agree with Hooray.
Hooray wrote in Fri Mar 09, 2018 6:51 pm:none of this would be "running" - it's just APIs, i.e. a few hundred symbols/references more
I think his argument is quite conclusive.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Plot2D and graph helpers

Postby Hooray » Fri Mar 09, 2018 8:33 pm

I don't claim that this is the way to go - but looking at other examples, it seems the "established" procedure (tendency) is to make APIs available by loading them into the global namespace, and only make actual features available in an optional feature where things are loaded "on demand".

To me, the FG1000 is also such an optional feature that is loaded on demand (which is Stuart doing), whereas the lower-level APIs are generally loaded into the nasal namespace.

However, to be honest, I don't remember how Richard's MFD/Emesary work is currently made available.

I do agree that it would make sense to carefully review this practice, especially if stuff is loaded unconditionally that is not use-case agnostic.

My take on stuff like the/a MFD framework would be that while it is in theory a cockpit/aircraft specific feature that should be optional, modern avionics are no longer prototyped/implemented and maintained that way - i.e. the standalone dialog-based use-case is certainly a valid one, which would imply that it is also okay to load such stuff into the canvas namespace.

Then again, I can relate to people doing gliders/soaring only, not wanting to load any of such stuff if they never use it at all.
On the other hand, a modern gliding computer could also be implemented using Richard's MFD framework.

Thus, as a compromise, I guess I would load these Canvas modules automatically, but check a boolean property first that can override this if people want to - which could also be configured via defaults.xml

Speaking in general, the Canvas system is a built-in subsystem that isn't intended to be optional - it is used for other parts of the in-sim UI experience, e.g. tooltips.
And a number of core devs have been tossing around the idea of adding 2D plotting support to fgfs for a plethora of different reasons - thus, I guess this qualifies as a valid general-purpose toolkit.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby Thorsten » Sat Mar 10, 2018 7:10 am

Guys, I'm sorry but you haven't really touched my actual question... and I still feel this needs to be discussed thoroughly.

So the question is - given that this is a partially redundant approach (my cdlg_widgets also contain clickspots and can be used for skinning) - is there any benefit in having these 'always on'?
(emphasis added)

I'm not really after the question if this chunk of code is a sizable performance hit, I'm after the broader question: Given that we seem to assemble toolkits with overlapping functionality, what do we do?

There's (as usual) several ways to skin a cat, and I'm fine to commit them side by side and let users take their pick what they want to work with. Your suggestion however amounts to treating your drawing helper classes privileged over mine, and it's less obvious to me why I would want to do that without going into a discussion of technical merits - if we make one approach not an approach but the approach, we should at least discuss why and how in some detail.

For instance, my drawing philosophy is pretty different - I don't ask a canvas element as output, I ask an array that contains the path data. The tangible advantage of this is the ability to post-process - the data arrays can be merged with others to create a unified path, culled for geometry and redundant gaps, projected, mirrored,... you name it - at vastly greater processing speed than going through canvas elements, because processing Nasal arrays involves zero property I/O or canvas backend work.

(I'll readily say that while this is better performance-wise, it's less elegant in terms of coding...)

Given these differences in philosophy, I don't see an easy way to merge the approaches - so in the end we're not discussing whether we want to commit this (moderately-sized) chunk of helpers, but whether we want to always and unconditionally load two large and likely growing classes of helpers side by side which in the end do pretty similar things.

And, sorry to say, that sounds not a super-desirable state of affairs to me.
Thorsten
 
Posts: 10729
Joined: Mon Nov 02, 2009 8:33 am

Re: Plot2D and graph helpers

Postby Hooray » Sat Mar 10, 2018 11:58 am

I don't ask a canvas element as output, I ask an array that contains the path data.

Actually, under the hood some of rleibner's work is using this method, too - in fact, he's using a function to populate the vector, at which point it can just be a callback, any callback populating such a vector, no matter the source (including other properties/functions or API calls)

Well, I don't know, but Stuart seems to have been running into the same problem basically - and he ended up generalizing things and adding his generalized helper routines to different parts of the "chain" - i.e. there is FG1000 specific stuff, then there is MFD specific stuff, Emesary related changes, as well as MapStructure and Canvas related changes.

Thus, it seems this is not primarily a matter of "merging" two similar toolkits, but identifying identical/overlapping functionality and moving that up in the chain of dependencies (think api.nas) and change the underlying toolkits to use those generalized routines.

I am not saying that this should be done, but suggesting that the two of you have the discussion how to proceed from here - maybe you can post links to source snippets illustrating your approach and rleibner can comment on how this relates to the plans for his toolkit ?

Like I said previously, there is certainly overlapping functionality - your use-case is currently aircraft-specific dialogs, whereas the primary use-case that rleibner has been dealing with is 2D plotting in general.

My suggestion would be look at the two toolkits and post a list of "components", i.e. parts that could -in theory- be used elsewhere, and then see if we can factor out certain stuff and promote it to become part of the core Nasal/Canvas APIs (i.e. stuff that is always available) and then decide if there is anything else that should definitely remain opt-in
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby rleibner » Sat Mar 10, 2018 2:05 pm

clm76 wrote in Fri Mar 09, 2018 8:14 am:Some problems with the new version of the oscilloscope :
- The number « 1 » (initialization) is staying when changing the values (screenshot 1).
- Number format problem in certain cases (screenshot 2).
- Traces are not displayed on the screen  : trace 1 = autopilot/internal/course-offset (value 13), trace 2 = autopilot/internal/nav1-course-error (value 18)

Version 0.0.6 (uploaded today) fixes all the 3 bugs.
Thanks clm76, you are my favorite tester ! :wink:
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Plot2D and graph helpers

Postby rleibner » Sat Mar 10, 2018 2:11 pm

Hooray wrote in Sat Mar 10, 2018 11:58 am:My suggestion would be look at the two toolkits and post a list of "components", i.e. parts that could -in theory- be used elsewhere, and then see if we can factor out certain stuff and promote it to become part of the core Nasal/Canvas APIs (i.e. stuff that is always available) and then decide if there is anything else that should definitely remain opt-in

It seems to me a good prudent compromise.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Plot2D and graph helpers

Postby Hooray » Sat Mar 10, 2018 2:16 pm

My impression is that your new clickspot-handling is rather generic already (seems you looked at Stuart's code) - so I would suggest that Thorsten takes a look to see if anything is missing in his opinion or not - and if it's complete enough, it could be promoted to the Canvas GUI module, which would also mean that Stuart could be using the same helpers, which would shorten his own code.

But again, it would make sense to get Stuart involved in this - he has got some additional complexity/requirements, because he's using a few abstraction layers due to Richard's Emesary framework.

And as far as I know, Thorsten's got routines that successfully annotate the UI via tooltips and can change the mouse cursor while hovering over click-able areas. So that's something that should probable be adopted ...
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby rleibner » Sat Mar 10, 2018 2:21 pm

Hooray wrote in Sat Mar 10, 2018 2:16 pm:seems you looked at Stuart's code
I did :)
Hooray wrote in Sat Mar 10, 2018 2:16 pm: it would make sense to get Stuart involved in this
Of course I agree. Is he following this discussion ? I would like to hear his opinion
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 246
Joined: Fri May 19, 2017 7:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: 2180.4.0
OS: Ubuntu 18.04

Re: Plot2D and graph helpers

Postby Hooray » Sat Mar 10, 2018 2:30 pm

Thorsten's work can be found here: https://sourceforge.net/p/flightgear/fg ... idgets.nas
I don't believe it's currently documented anywhere though - you may be able to find examples in the shuttle repo.

Here's the routine setting up hotspot-specific tooltip/cursor handling:
Code: Select all
setContextHelp: func (f) {

         me.frame.addEventListener("mouseover", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'left-right'}));
         f("mouseover");
           });

         me.frame.addEventListener("mouseout", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'inherit'}));
         f("mouseout");
           });

         me.fill.addEventListener("mouseover", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'left-right'}));
         f("mouseover");
           });

         me.fill.addEventListener("mouseout", func(e) {
         fgcommand("set-cursor", props.Node.new({'cursor':'inherit'}));
         f("mouseout");
           });
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Plot2D and graph helpers

Postby Thorsten » Sat Mar 10, 2018 2:47 pm

Actually there's a whole zoo of drawing primitives for displays and HUDs - arcs, arcs with tickmarks, ladders, lines with single or double-sided tickmarks, triangles with various reference points,...

The idea being that to paint a HUD, you just call the ladder function, optionally clip what you don't need, shove the whole thing to a draw routine and get the canvas element you want back.

That's similar in spirit to the vertical, horizontal, grid, dashed-line,... the 2d plot code contains - though different in implementation.

It's distinct from the widget lib which proposes to provide a nice-looking set of elements for dialogs (unlike the geometry primitives, the widgets each come with functionality, so in a dialog you only need to call a setValue() to see a graphical response etc.) Conceptually the widgets would use geometry primitives, although I haven't come across a case yet where I actually need this.

I don't believe it's currently documented anywhere though - you may be able to find examples in the shuttle repo.


For the geometry primitives - call function, get array containing the shape back, that's really all.
Thorsten
 
Posts: 10729
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest