Torsten wrote in Sun Jun 15, 2014 8:22 pm:I hope nobody every backports FGPanel to the fg core. The fgpanel is an extract of old fg functionality, the old 2d panel code to be more precise. It's goal is to run standalone on old and/or slow hardware and to render old steam gauges with great level of details.
Well, this has already been discussed on the devel list several times - the idea is not to touch fgpanel itself, but rather to allow FG to start up in a mode that would allow most subsystems to remain disabled, work that needed to be done as part of the reset/re-init effort anyway. So FlightGear as a whole would benefit from more fine-grained initialization/subsystem control.
And fgpanel itself, like you said, is "just" the legacy 2D panels code, which we're hoping to unify/modernize via a Nasal/Canvas parser anyway. Here, HTML5/Canvas and JavaScript would help us very little unfortunately, unless you're volunteering to handle the integration
I would not suggest implementing PFD/MFD like devices using FGPanel as there are better ways to do so.
I am currently experimenting with HTML5 Canvas and SVG using the new websocket and AJAX interface. No more spooky XML files, no proprietary scripting language without a debugger. Just standard HTML, CSS and JavaScript and 100% cross platform.
right, had we had that option 5+ years ago, this would have surely become a "standard", as it is extremely flexible, and doesn't keep the main loop busy.
And we would have the added advantage that these are all W3C "standards"
(Besides, I wouldn't exactly call Nasal "proprietary":
http://en.wikipedia.org/wiki/Proprietary )
But there are other disadvantages involved here, those that come with running stuff outside the main process, i.e. due not being able to easily access certain data structures.
You've already worked around some of those by exposing FGPositioned via AJAX meanwhile, but obviously things get tricky once we're dealing with binary data that need to be accessed at higher rates, such as images or image streams.
A standalone canvas mode would not just allow MFDs to be run, but also any other Canvas-based graphics, i.e. HUDs, 2D panels, including even our GUI - which includes arbitrarily complex displays.
For that reason, even if nobody else is going to work on this, I am still going to pursue this.
Of course, thats for external displays only. For displays inside 3d models, the FG-Canvas/Nasal is the way to go (at least until Tom implements Gecko/SpiderMonkey
The main problem here is lack of consistency: we've seen half a dozen of glass cockpit related efforts over the years - including stuff like OpenGC (early 2000s) and FGGC (mid 2000s), and quite a few others in the meantime.
At the end of the day, this always meant that we had competing, and even conflicting, technology stacks involved - where one technology (instrument/MFD) would not work within the other run-time environment. Canvas, coupled with HLA (or even just remote/telnet properties), has the potential to solve this once and for all. We've actually been in touch with several avionics manufacturers that are now hoping to use the combination of FlightGear/Canvas + J661 for these reasons.
Now, given your recent work, I fully realize that we're probably not going to agree here - but I guess we have to accept that there are people here who've been working on Nasal/Canvas-based solutions for problems that you are now solving in a very different, and very elegant/standards-oriented, way - which is still not "native" to FlightGear, like you said.
But, ultimately, HTML5/Canvas + JavaScript isn't going to be hardware-accelerated in the form that FlightGear's Canvas system is. Then again, what you mentioned regarding HTML5/JavaScript support isn't all that far-fetched either - OSG can certainly already render WebKit views to a texture. So this is, once again, one of those cases where FlightGear turns out to be a very much disorganized, with even conflicting solutions being worked on by different contributors- obviously, this isn't the first time, and it's also not going to be the last time something like this happens. I think we simply have to embrace the opportunity and see what prevails.
From my standpoint, having -yet again- different types of instruments that are specific to an external run-time environment is very much a maintenance nightmare.
Technically, I even agree that a HTML5/Canvas+JavaScript based system would have been great to have years ago, and it would have helped unify several obsolete technologies - but meanwhile, Canvas is our most solid and most unified approach to tackle those challenges, without them being specific to an external run-time environment, while still providing all the theoretical benefits, plus quite a few more. There used to be a talk on the devel list about adopting JavaScript/XUL several years ago, back then, nobody like the idea - but some of the recent mongoose work looked very much in line with the debate we saw back then.
Obviously, that doesn't have to mean that things inevitably have to remain just accessible through Nasal though.