Board index FlightGear Development Canvas

Update to canvas API and SVG parser

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: Update to canvas API and SVG parser

Postby Gavinmc42 » Fri Feb 22, 2019 4:38 am

I have found in OpenVG a lot can be done with rect, rounded rect, circle and text, I suspect the same can be done with the simplest SVG.
Nasal generated SVG is outside my comfort zone at the moment, I need to upgrade my PC as it will not run FG.
At the moment I cannot even see how the text in some of the SVG files is done.
If it is via paths then that might be slower than letting the Pi to use it's native OpenVG text method.

I just found out Lazarus/Free Pascal can do SVG and has a SVG viewer as part of the bgracontrols library.
I may end up combining the SVG and Lazpaint into an instrument design tool that makes a more native Pi OpenVG file.
It probably would be possible to even use this as a PC based SVG display with even Pi's able to run Laz/fpc too.
One of the issues (advantage?) with Pi' is there is so many way to do things these days.
The latest Pi OpenGL drivers are getting pretty good now too, which opens up another method.
That Canvas.draw link is giving me ideas.

What I want to figure out is the minimum, simplest software needed to make a Raspberry Pi Zero useful as separate instrument displays.
I noticed telnet was/can be used to send the relevant data out.
That would require a Ethernet Pi, perhaps a Pi3B+ and with a Cluster hat and 4 x Zeros I could do a system with 5 HDMI/DVI monitors.
That would make a full NG glass cockpit possible, use a wide 1920x1080 screens with a bezel to split the display into two?

I like the Android display idea as they have touch screens so I see the advantage of the Phi/Browser based software.

Anyway you guys have giving me lots to read and try to play catchup.
I have yet to benchmark my OpenVG methods, which is why I want to try using existing FG stuff.
I also want to make sure it is not FG/Nasal specific but a generic method of using OpenVG/OpenGLES on Pi's for instrument displays.
That way I or anyone can make Star Trek or Orville bridge /engineering/medical ….displays as well as real air/space vehicle simulated displays.
Or car dashboard for a racing simulator for the kid.
Or to design UI's for any Pi based instrument :P

Pi Zero's are very low priced and second hand DVI monitors can be free or <$20.
Those with USB ports are useful and the 5V can power the Zero or even a Pi A+ or B+.

Thanks for the ADI ball link, getting my head around that is why I stopped developing this idea in 2017.
https://ultibo.org/forum/viewtopic.php? ... =PFD#p5409
Really would love to see how this is coded in a real glass screen display.
Currently I suspect I might have to use OpenGLES.
I know that Pi's can handle at least 20,000 triangles at 60fps.
Even 3D instruments won't need that unless you want to do lighting and shadow effects :D

What changes, will just be a few properties and if the Pi just get those it does not need a redraw of the whole display.
Pi's in effect become cheap graphical coproccessors for Nasal?

I don't intend to make any FG feature requests or improvements as I have only a basic understanding of how FG works.
In fact it is probably better if I stay in the dark and not get too distracted.
I now know enough to keep me busy for some time.
Will get back here when something works, which at my current rate of progress might be a year or two :roll:
Gavinmc42
 
Posts: 6
Joined: Mon Feb 18, 2019 12:52 pm

Re: Update to canvas API and SVG parser

Postby Richard » Fri Feb 22, 2019 4:59 am

Hooray wrote in Thu Feb 21, 2019 8:18 pm:
legoboyvdlp wrote in Thu Feb 21, 2019 7:35 pm:Just to clarify a point, props.nas is not slow: in fact, it is now much faster since it was implemented in cppbind than setprop or getprop. However, whether using props or getprop property IO is indeed a bottleneck.


Unless you are talking about a recent change/commit or ongoing development, I think that you are very mistaken here.

As a matter of fact, what you are saying is a contradiction: props.nas is either re-implemented in cppbind or it is implemented in Nasal (as it currently is).


He's not mistaken at all.

I really want to stamp out this fallacy that using getprop and setprop is a good idea. It isn't and never has been. Especially now that getprop/setprop are much slower than using props.nas. Using props.nas is a much better way to access the property tree as it is a proper API - and thus I wish nobody had ever said use getprop/setprop because I've got lots of code that does and it shouldn't because now I have to recode it to use props.nas.

My advice to all Nasal developers is never to use getprop/setprop

The performance improvements are due to optimisations that James made.

The performance increase has been verified by several of us aircraft developers.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Update to canvas API and SVG parser

Postby Thorsten » Fri Feb 22, 2019 6:46 am

I really want to stamp out this fallacy that using getprop and setprop is a good idea. It isn't and never has been. Especially now that getprop/setprop are much slower than using props.nas.


I think the last result verified by a number of people was that if you need to get the property node and then write a property via props.nas, setprop() is faster by some margin.

If you have the property node stored, then node.setValue() is faster than setprop().

So for one-time shots where you don't want to store the node, setprop() is a good idea, for something that's written per frame and it's worth keeping the pointer to the node it is not.

***

(And a few years ago, the situation was quite different and setprop/getprop were unconditionally faster, I ran quite excessive tests on that point ). Today they are slower if you have the node, but not by that much.

So the whole thing is a bit more complex...)

***

Having said that, avoiding property I/O is yet faster by a factor 100 or so (in fact it's so fast it's hard to measure properly) - letting two routines talk via Nasal variables rather than via the property flat-out beats everything, so does checking whether a property really has changed against a Nasal cache before writing it.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Update to canvas API and SVG parser

Postby Richard » Fri Feb 22, 2019 3:05 pm

Yes; it's worth saying that avoiding the property tree for stuff that communicates just between Nasal is the fastest possible way of doing things (in Nasal). Using the property as Nasal variables, arrays etc. is to be discouraged. The property tree is there to interact with the simulation modules, not other Nasal modules.

The main problem I have is that setprop will usually be run after initialisation; and I guess what I didn't make clear is that part of the deal with properties is that all of the (props.nas) nodes that you wish to write to or read from should really be setup during the initial load (either at module scope, or class/object scope).

Also props.nas provides an API layer; which in turn gives us more possibilities for future optimisations - whereas setprop/getprop using strings isn't quite the same.

With the 2018.4 / 2019.1 I added the ability to flag anything that overruns (by more than a certain amount) and this can produce some surprises. I've already optimised a few things to use nodes rather than methods. It's one of the main causes of losing a few FPS every now and then.

The thing that most people don't realise is that whilst a single setprop() may be faster that looking up a and using a node these build up and can affect the frame rate. Generally most aircraft developers aren't paying enough attention to doing the least amount of work possible inside the main loop - which is why it will always be better to setup these nodes at the start and just reference them.

There are exceptions to this rule; such as when the node name cannot be known during initialisation - but for the general case of reading and writing moving the lookup work out of the frameloop (or even from listeners) will pretty much always provide the best performance.

Usual caveat of all of the above being IME and IMO.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Update to canvas API and SVG parser

Postby Thorsten » Fri Feb 22, 2019 3:20 pm

Generally most aircraft developers aren't paying enough attention to doing the least amount of work possible inside the main loop - which is why it will always be better to setup these nodes at the start and just reference them.


Agreed.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Update to canvas API and SVG parser

Postby wlbragg » Fri Feb 22, 2019 4:54 pm

There are exceptions to this rule; such as when the node name cannot be known during initialisation

For example, would that possibly be a property derived in an FCS Function or Filter?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Update to canvas API and SVG parser

Postby Thorsten » Fri Feb 22, 2019 6:16 pm

Not really - regular property I/O reading from filters is best managed by storing a pointer to the node and then querying that. The filter/property rule requires you to specity a property name when you code, so you can use that name upon Nasal init.

Use cases where you can't know whether a property exists up-front or where you can't know the name tend to be a bit on the exotic side.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Update to canvas API and SVG parser

Postby jsb » Sat Feb 23, 2019 6:13 pm

My recent work on nasal performance is documented on the wiki http://wiki.flightgear.org/Nasal_perfor ... benchmarks
Currently the most performant way to access properties is to create a props.Node object for the property and use the myNode.setValue() / myNode.getValue() method in any update loop. Once you have the object, this is about 25% faster than setprop("/path/to/prop", value);
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Update to canvas API and SVG parser

Postby Hooray » Sun Feb 24, 2019 5:30 pm

Note that Thorsten is right, it's not a simple back and white issue, for the same reason is Richard right, having an API (framework) is generally a good idea so that things can be benchmarked/profiled and optmized in a holistic fashion without having to re-architect tons of code. However, as has been said, the setprop/getprop APIs used to be much faster in comparison - even though that depends obviously on the use case.

It the mid-term, a native cppbind-reimplementation would make sense, but in the long-term, something like a property manager would make more sense, i.e. where modules can specify their dataflow requirements in terms of properties, to reduce unnecessary I/O.

Also, some canvas APIs cause rather heavy "traffic" in terms property I/O, so there's that 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

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest