"Advertising FlightGear"

[icecode]

This is wrong. Apart from threaded Nasal Garbage Collection, there is pretty much nothing to gain from threading. As far as I am aware, most systems are GPU-limited or Terrasync-download-limited, not CPU-limited. And for those, threading is not a magical answer. Threading, if introduced, is not guaranteed to even make things faster. But it is guaranteed to introduce dead-locks and nasty racing all over the place. And note that a thread-safe property tree with locking for all operations will be a lot slower and likely introduce a big CPU bottleneck!

A few tests by Richard suggest otherwise, see https://sourceforge.net/p/flightgear/fl ... ewer/tree/. Not having to wait for the frame logic to start the OSG rendering process gives a 20ms to 50ms improvement on my machine, depending on the aircraft complexity. Being constrained by OpenGL's enforcement of a single thread per context doesn't help either.

Also, FG is CPU limited in almost every system I've encountered (excluding very old machines and laptops with very limited integrated CPUs), as is expected of simulation software where FDM, systems (and Nasal in our particular case) take the most time. The complexity of the scene graph also makes OSG cull times very significant on every machine, and draw call submission is very expensive on lower-spec machines. Again, as I've told you on another thread: if you own an integrated GPU from 5 years ago, your system is not a good system to benchmark FG on. This is an intensive 3D application, not a web browser.

[Hooray]

Sorry bugman, but you are very wrong - and I encourage you to share any data/stats/evidence to make your point (or even just "authoritative quotes" ).

Let me try to elaborate:

Over the years, a number of senior contributors (even just counting those with a track record in contributing to the rendering back-end in FG/SG) have repeatedly pointed out how FlightGear is easily CPU-bound for many end users, amongst others, because of the way the scene graph is poorly assembled/structured (which is much less likely to show up on a a modern gaming rig with plenty of spare horsepower); once you dump/inspect the scene graph, you will realize it is using a sub-optimal and very roundabout structure, one that got introduced when the OSG migration was initiated.

Specifically, Tim, Mathias, Stuart, James and Fredb have been pointing a number of long-standing issues regarding the structure of the scenegraph, to name just a few examples:

* redundant/unnecessary Statesets
* redundant/unnecessary Osg::Transform nodes
* tons of Osg group nodes, for animations to work
* redundant nodes for materials & effects to work, even for nodes that don't use any
etc (this is really just off the top of my head, i.e. there are certainly other things I am missing right now, it's just to prove the point)

Given that the scene graph is computed on the CPU side, it's obvious that some people may indeed be quickly CPU limited.

Threading, if introduced, is not guaranteed to even make things faster. But it is guaranteed to introduce dead-locks and nasty racing all over the place. And note that a thread-safe property tree with locking for all operations will be a lot slower and likely introduce a big CPU bottleneck!

Again, you're preaching to the choir: I never talked about a "threadsafe property tree", people wanting that to improve FlightGear's overall runtime performance (frame rate/frame spacing) , don't understand that fine-grained threading ("per property") isn't going to buy us anything at all, like you say (but not just due to synchronization overhead).

FlightGear's subsystems are not designed with concurrency in mind, so it's pointless to make a data structure like the property tree threadsafe, unless you identify tasks that lend themselves to threading - threading at the property level is kinda pointless as long as there is only a single global property tree that all subsystems share.

The canvas GUI you speak of is not a replacement for the current PLIB GUI (PUI) that all users interact with.

Actually, it is and it can be that, and even much more - in the same sense that the Canvas system as a whole is a replacement for any hard-coded OD_Gauge based glass instrument.

Because at the Canvas/Nasal level, the system can trivially parse/process and render 99% of our existing PUI/XML dialogs/widgets, without requiring C++ space modifications.

We can render a functional Canvas based menubar/popup menus, and we also can render functional Canvas widgets/dialogs responding to mouse/keyboard events as needed.

As others have pointed out previously, PUI is a rather basic and limited GUI engine - and in FlightGear, we're only just using a subset of PUI widgets.
And we really only need to support a tiny subset of this subset to render most existing PUI/XML dialogs, without them having to be modified - and without them having to be under the control of the project (i.e. referring to dialogs outside fgdata/fgaddon respectively).

Any aircraft developer who's ever done a PFD/ND or EICAS/ECAM, has done more work than is needed to implement a single widget.

Given that, we have all the manpower and expertise we need, because Nasal + Canvas that's what aircraft developers are likely to know anyway

No core developer wants to see a Canvas replacement for the PUI.
Every core developer is in agreement that PUI will be replaced by Qt Quick and the QML markup language - that was discussed at length and enshrined in the FlightGear Policy and Roadmap Document.
No core developer wants the burden of maintaining our own FG specific GUI toolkit, as all core developers are acutely aware that fully-fledged GUI toolkits are monsterous.

You make it all sound clear-cut like it's a black and white issue, while the truth is far from it.
In fact, do you even remember that there were/are senior core developers opposed to mandatory Qt5 integration, i.e. the reason why they didn't want to make it non-optional ?

So your summary, too, is a rather serious misrepresentation of affairs (as usual ...) - in fact, even James himself came up with the idea originally.
And when asked on the devel list about his plans for a QtQuick UI, he specifically conceded that plans were very much in flux still (even back in 2018).

Also, let's not forget that TheTom (who implemented all of the existing CanvasGUI subsystem that you so conveniently forget to mention), happens to be a core developer, too

Ok, time for a little reality check - let's look at what other core developers stated in the context of a Canvas GUI replacing PUI:

https://sourceforge.net/p/flightgear/ma ... /35157325/

If that is true [that we could have a canvas based PUI replacement within a couple of weeks/months time], probably nobody objects against removing PUI and replace it by CUI, keeping the old syntax.
At least for a while. Dropping PUI would be a huge step forward.
[...]
I [am] not objecting against the CUI as long as It stays out of the way
if not enabled (or explicitely disabled).

https://sourceforge.net/p/flightgear/ma ... /29584553/

using the Canvas also for the GUI would give us the advantage of a
unified rendering backend for any type of GUI/text rendering and also
the ability to use the same widgets everywhere - eg. use them also
inside aircrafts for CDU GUIs or other displays...

https://sourceforge.net/p/flightgear/ma ... sg29584553
I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.

we need a bit of discussion about the architecture for this approach, especially to define a widget abstraction (maybe C++, maybe nasal) so dialog authors can't break widget functionality unintentionally, but aside from that I can't see many potential problems; Nasal can already process the GUI files since they're property lists.
[...]
The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with never OpenGL versions that forbid old style GL calls)
[...]
it’s great if Canvas is as the point that we can actually consider such things, and hopefully the actual arrangement of screens + widgets is easy to evaluate and adjust.

https://sourceforge.net/p/flightgear/ma ... /36198253/

Having all three options available is a bonus. So please go ahead with
Qt for the simulator settings, Canvas for aircraft specific in-window
options and Phi for instructor stations.

Canvas has the advantage for the aircraft developers to make really
aircraft specific options available. These vary so much across the board
that Qt won't be able to address them anyhow. And to be honest, I do
like the 3d option Canvas provides.

https://sourceforge.net/p/flightgear/ma ... /34196458/

building a QT based GUI is not in any way meant to obstruct the further development of a Canvas based GUI.
[...]
The beauty of open source is that there's more than one way to do things, however.
Especially in a completely modular environment.

https://sourceforge.net/p/flightgear/ma ... /24467194/

Qt widgets can be drawn into OpenGL buffers. That doesn't change the fact that it would be a great deal of work to port our GUI to Qt, and it would introduce a very large external dependency. Having seen the fit pitched when I started using boost... Now, big projects can get done, and motivated individuals with time on their hands can work wonders. We should keep in mind the relative importance of the GUI system to the whole flying experience and judge whether it would be worth the effort to do a huge rewrite in this area.

You may wish to see that Canvas replaces all, but that is not at all where the project is heading.

Please stop spreading misinformation, and check your facts (i.e. look up the links I shared).

Hopefully, you'll realize then that it was James himself, who came up with the idea to unify the 2D rendering back-end via the Canvas system (including specifically the idea to use the Canvas to replace PUI).

And that he has in fact been encouraging other contributors to help with that, most recently by encouraging people to actively work on retargeting the 2D panels and HUD subsystems to work via the Canvas, which incidentally, also is "enshrined" (like you put it) in his earliest edits to the corresponding wiki article: http://wiki.flightgear.org/index.php?ti ... did=124348

Finally, had you looked up the previously posted pointers, you would have realized that James and others have been pointing out issues related to OSG/Qt5 interaction. But since you're obviously not overly interested in clicking those links, here's some authoritative statements from Robert Osfield himself (OSG project lead):

https://groups.google.com/d/msg/osg-use ... SD3DlPAAAJ
The threading models that the OSG
provides reflect this, enabling threading of the update, event and
cull traversals in parallel with the draw thread. This is all
possible with a Qt based viewer, but different versions of Qt add
their own caveates/problems. If you care a about full screen
real-time performance then Qt probably isn't the best tool to use,
native osgViewer based viewer will work much better, but if you need
the 2D GUI elements that Qt provides then you'll need to jump through
the extra hoops that Qt throws into the mix.


https://groups.google.com/d/msg/osg-use ... _2gPlZAwAJ
Unfortunately Qt has created a
series of problems on the threading front that we've had to try and
work around, Qt then goes and moves the goal posts though between
releases. it's been a real pain to try and keep osgQt working well
over the years. If you don't need a traditional 2D UI then it's
generally best to avoid Qt as it causes problems because it has it's
way of working that doesn't fit well with the needs of real-time
visualization.

(It's also worth noting that Robert has been making these statements despite KDAB (James himself) showing up on osg-users to help improve OSG/Qt5 integration)