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 Hooray » Sat Mar 10, 2018 4:10 pm

yeah, but the 2D stuff that you have been reviewing was never intended to do any of that - it was all inspired by plotting values in a 2D diagram with an x/y axis only.
So it's probably pretty safe to say, that it won't be of much interest for creating HUDs, I guess ?

PS: Here's a link to the shape drawing routines that Thorsten is probably referring to (again, it probably makes sense to post URLs or at least file names as pointers, so that everybody is on the same page): https://sourceforge.net/p/fgspaceshuttl ... s_draw.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: Plot2D and graph helpers

Postby Thorsten » Sat Mar 10, 2018 4:15 pm

On what level does that matter? You call a function, you get a canvas element in the end - it's the same principle that's being applied, whether you draw a dashed line for a plot or a ladder for a HUD.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Plot2D and graph helpers

Postby Hooray » Sat Mar 10, 2018 4:26 pm

I think there is a misunderstanding here - I am aware of the internals - it's exactly how the MapStructure framework is implemented, too (with additional helpers for making things style-able and the property-back-end configurable, too).

It is probably true that there are different philosopies in use here - but ultimately it all ends up in vectors (arrays) anyway, because that's what OpenVG deals with too.

Like you said, widgets could be using a back-end that has lower-level helpers to create the widgets, which would ideally be close to what OpenVG expects - for performance reasons.
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: Plot2D and graph helpers

Postby clm76 » Sun Mar 11, 2018 12:06 pm

@rleibner
Version 0.0.6 (uploaded today) fixes all the 3 bugs.
Thanks clm76, you are my favorite tester ! :wink:

It's ok now. Thanks. It's a very useful tool ! :)
clm76
 
Posts: 204
Joined: Tue Oct 30, 2012 9:18 pm
Location: France - LFOH
Callsign: F-GCLM
Version: 2020.4.0
OS: Linux Mint 20.2

Re: Plot2D and graph helpers

Postby Hooray » Sun Mar 11, 2018 12:08 pm

thank you for all the testing and feedback, too !!
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: Plot2D and graph helpers

Postby Thorsten » Tue Mar 13, 2018 8:16 am

Okay, let's approach this from a different angle - Rodolfo, how do you see this developing? Are the 2d plot helpers essentially ready? Or could you imagine expanding the kit? Do you forsee making plots only, or also draw other things?

I agree we have limited overlap between libs right now - so is that going to stay that way?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Plot2D and graph helpers

Postby rleibner » Tue Mar 13, 2018 4:55 pm

Thorsten wrote in Tue Mar 13, 2018 8:16 am:Okay, let's approach this from a different angle - Rodolfo, how do you see this developing? Are the 2d plot helpers essentially ready?
...

If by "essentially" you mean basically/ fundamentally, I'm sure they are ready.
I've made an effort to include not only my needs, but to foresee others.
When developing Oscilloscope (and then PAR) I had to tune some functions in order to make them more general/flexible/efficient.
You know better than me that no code can be considered definitive, but I'm sure the only way to improve them is to let other Nasal coders to use them and have enough feedback.
And I do know that if my next work involves a GUI (or any graphic output), my first step will be to include a copy of the 3 (plot2D, graph, skinnable) into the new addon folder.

On the other hand, I have no objections to coordinate with other authors in order to reduce overlap and reach a better result.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Plot2D and graph helpers

Postby Thorsten » Tue Mar 13, 2018 4:59 pm

Well, the question I'm trying to decide here is - do we forsee overlap in what we're doing, in which case it would make sense to discuss whether we'd do better with a common class we both add to - or are we really aiming to do quite separate things, in which case we leave everything side by side.

I know code is never definite or finished, but that doesn't help me here :mrgreen:
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Plot2D and graph helpers

Postby rleibner » Tue Mar 13, 2018 11:00 pm

Thorsten wrote in Tue Mar 13, 2018 4:59 pm:Well, the question I'm trying to decide here is - do we forsee overlap in what we're doing, in which case ...
Reading your CdlgWidgets.nas I see the overlapping areas.
BTW, we both have some overlapping stuff with stuart's work.
Would be great if we could accord our interests and priorities, so we can profit the work of each other instead of duplicate efforts.

So, let me comment my own work:
In general, my goal is to facilitate the creation of canvas GUIs and stand-alone instruments.
    plot2D.nas is nothing but a set of wrappers calling general API methods.
    graph.nas allows to use customized local coordinates to call plot2D methods.
    skinnable.nas facilitates to skin/dress a canvas with multiple overlapped images, and manages the mouse events.
Maybe one day I'll aim to create beautiful UI full of amazing widgets ... but not today. I would honestly prefer to rely on someone else's work.
And I'm definitely not interested in creating aircraft-specific instruments.

It would help me if you comment your own work, your goals and non-goals.
As I said before, I see with good eyes an eventual collaboration between us.
This implies that both of us are willing to make our points of view more flexible and even touch up (generalize/customize) some code for mutual benefit.
I am.

Regards,
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Re: Plot2D and graph helpers

Postby Hooray » Tue Mar 13, 2018 11:24 pm

Regarding skinnable.nas, my impression is that this is very much overlapping with Thorsten's widget framework - i.e. this could potentially be a low-hanging fruit.
Right now, I believe, that skinnable.nas is dialog/canvas-centric, right ?
Thorsten, however, basically seems to require "skinnable elements" in general - not just a single/whole canvas or dialog, but potentially a vector of skinnable elements (objects/instances) that can be arbitrarily aligned.

I also think that Thorsten shared some screenshots displaying procedurally generated gauges that he's connecting to arbitrary properties, referring to:

Aircraft-specific dialogs
Thorsten wrote:Here's a quick proof of concept of the analog gauge widget with two raster images filched from the internet (no, I didn't commit this because it's not licensed) - works like a charm, and raster images being raster images with gradients and shading, this'll probably look better than any SVG solution - basically you can base this on an actual cockpit photograph if you have one.

Image

The actual code to get it in is very simple if the widget lib is used:

Code: Select all
me.gauge_test = cdlg_widget_analog_gauge.new(me.root, "Aircraft/SpaceShuttle/Nasal/canvas/gauge.png", "Aircraft/SpaceShuttle/Nasal/canvas/gauge_needle.png");
me.gauge_test.setTranslation (50, 150);
me.gauge_test.setAngle(30.0);
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: Plot2D and graph helpers

Postby Thorsten » Wed Mar 14, 2018 8:06 am

It would help me if you comment your own work, your goals and non-goals.


Happy to.

I'm aiming at providing a toolkit for creating aircraft-specific dialogs with canvas at the expense of calling just a few lines of code (as mentioned earlier, if one had a parser one could do this from xml, but many aircraft creators are familiar with canvas from instruments anyway).

The idea is that you use raster images for the layout, onto which canvas path and text element widgets are drawn procedurally - so for a typical dialog you'd

* create a canvas
* create the unchanging design as raster image and load it into the background
* create the changing elements in the init() method of the dialog by instancing widgets with certain parameters (which may in turn use raster images)
* move them to their position using setTranslation()
* update the dialog elements in an update() method as long as the dialog is open (such that graphics is generally automatically updated by just changing the value)

This'll have clickable switches (using indexed raster images for the switch state), drag'n'drop of elements, optional context help when hovering the mouse over an active element), and whatever else looks nice.

Click events can either be assigned to a widget itself or, using the clickspot widget, to an active area of the background image.

In addition, largely from creating the Shuttle HUD and PFD, I have a lib of procedural element generation functions for e.g. drawing a ladder (useful for HUDs) etc.

The main advantage of doing this procedurally as compared to SVG is that if you mess up the ladder spacing in SVG, you have to re-do it all - if you do it procedurally, you just change the parameter and it's good. That's kind of similar in spirit to what your grid and dashed line functions do.

I'm currently developing all of this inside the Shuttle repo to have a concrete use case and periodically move the generics to FGData.

It'd be good if you take a short look into

https://sourceforge.net/p/fgspaceshuttl ... al/canvas/

canvas_widgets.nas are the dialog widgets, they're instanced in
canvas_dialogs.nas - currently you can study a (rather involved) example of the propellant dialog where you can add a child window for details of every tank and the temperature distribution
canvas_draw.nas contains simple shape functions which return elements, if you want to see a use case

https://sourceforge.net/p/fgspaceshuttl ... D_main.nas

is the HUD - completely SVG-less, it's all drawn by calling shape functions for the various elements.

May I suggest you look a bit into the code, perhaps (if it runs for you) fire up the devel version of the Shuttle in orbit and look at the dialogs how you like the concept - and then we can discuss better whether we ought to join forces or provide separate toolkits.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Plot2D and graph helpers

Postby Hooray » Wed Mar 14, 2018 3:19 pm

Thorsten wrote in Wed Mar 14, 2018 8:06 am:The main advantage of doing this procedurally as compared to SVG is that if you mess up the ladder spacing in SVG, you have to re-do it all - if you do it procedurally, you just change the parameter and it's good. That's kind of similar in spirit to what your grid and dashed line functions do.


Can you make an informed guess comparing the two approaches regarding the runtime overhead ?
I am asking because Stuart mentioned the complexity of the SVG-based HSI and altitude/speed tapes/ladder for the FG1000 - so it would be interesting what this means from a workload/performance standpoint, i.e. if it's even worth it to use SVG for these things, or if your code is likely to perform better ?
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: Plot2D and graph helpers

Postby rleibner » Wed Mar 14, 2018 3:35 pm

Hooray wrote in Tue Mar 13, 2018 11:24 pm:Right now, I believe, that skinnable.nas is dialog/canvas-centric, right ?
Yes, it is.
In general, here the event targets are the canvas itself.
Only when necessary ('tip' and 'cursor') , ad-hoc objects are created 'on the fly':
Code: Select all
createTip: func(hot) {
 var region = canvas.plot2D.rectangle(me.root,[2*hot.tol, 2*hot.tol],[hot.x-hot.tol,hot.y-hot.tol],'#01010101','#01010101',hot.tol*.75);
 region.addEventListener("mouseover", func(e) {globals.gui.popupTip(hot.text,3);});
 },

Comparing this with the Thorsten's approach (a vector of elements as targets), the point is the advantages/disadvantages for each one. I'm not very clear about that.
Rodolfo
*************************
Non-shared knowledge is lost knowledge
User avatar
rleibner
 
Posts: 269
Joined: Fri May 19, 2017 8:17 pm
Location: Uruguay - SUMU
Callsign: CX-BEX
Version: next
OS: Ubuntu 18.04.4

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 6 guests