Thorsten wrote in Sat Dec 17, 2016 12:47 pm:So in my view there's zero need to encode this as flags and properties - getting the calibrated view point is hard, applying parallax from there is a piece of cake.
Actually, the "hard part" should already be part of the existing C++ code implementing the legacy HUD, right ?
So porting that code to integrate with the Canvas properties at the placement/element level would not necessarily be rocket science.
Otherwise you do have a point though - when it comes to Nasal/Canvas vs. C++ and OSG we've been approaching a "parity situation", i.e. it's often possible to accomplish something and implement certain functionality using both approaches. However, the real issue is actually two-fold, which is kinda backed up by your introductory posting here:
You have meanwhile an enormous, and basically unprecedented, track record when it comes to FlightGear matters, especially in the rendering department, i.e. you have an unprecedented track record in rendering matters despite not exactly writing/committing C++ code on a daily basis; which is to say that you are able to implement sophisticated features without having to touch any C++ code - which is mainly because of your expertise when it comes to Nasal, effects and shaders - i.e. you usually know exactly how to integrate these features to make effective use of these, and other (think property rules), technology stacks.
However, let's also keep in mind that you are also in a fairly exceptional and probably unique position, in that your background regarding maths/physics puts you in an excellent position to work out even the most sophisticated intrinsics of stuff that would otherwise take people months to figure out.
The other point I was hoping to make when I suggested to tackel this at the sc::element/sc::placement level is that of establishing, and maintaining, compatibility with other important features, use-cases and long-term goals (think performance, optimization).
As you should meanwhile know, I am far from opposed to Nasal space situations - however, the way Nasal is integrated with FlightGear, and exposed to aircraft developers has been hugely complicating matters for people wanting to re-architect certain parts of FlightGear - no matter if that meant implementing better threading support, refining support for multi-instance setups (FSWeekend, LinuxTag, dual-pilot/shared-control).
This is one of the reasons why an increasing number of core developers, and more recently you yourself, have been encouraging contributors to port/reimplement certain Nasal-functionality in the form of property rules, especially when it comes to rendering related contributions, i.e. stuff that may possibly run once per frame.
In general, Nasal has obviously been a huge technology-enabler - but in reality we really need to make sure to restrict the way we're using Nasal, either by moving away from Nasal, or by encapsulating its use, which means that we need to work out a way to formalize and standardize on generic interfaces and building blocks, which can provide a sane migration path if/once Nasal turns out to become a bottleneck.
The way we have been using Nasal is hugely problematic due to a variety of reasons, the lack of code-reuse and standard building blocks being two of the more obvious ones.
Had we provided bindings to SGSubsystem/SGSubsystemMgr, we would not have to "pseudo subsystems" implemented on top of timers and listeners these days.
When it comes to Canvas, it's extensive use of Nasal is basically importing all of Nasal's challenges, which is why it doesn't come as a surprise that most Canvas-based contributions are basically facing pretty much the same challenges that most Nasal code is facing.
De facto, there isn't a single good reason why rendering related Canvas code should have any runtime Nasal dependencies that are potentially triggered per frame - at runtime, we could do away with listeners and timers entirely, at which point merely the initialization/setup overhead would be caused by Nasal, but everything else would be using native C++ code and OSG data structures behind the scenes.
Right now, we have tons of Canvas-based features that implicitly require Nasal, i.e. tons of potential context switches - most of them happening per frame, or using a pseudo-scheduling mechanism build on top of split-frame loops, i.e. spread across multiple frames.
Ultimately, what this is really all about is
animating a Canvas without requiring Nasal to do so at runtime - all that is needed is to encode the animation semantics at the property level, and at that point property rules and/or state machines could take over, i.e. native C++ code - no matter if that means translating an element or transforming a nested groups, we really don't want to depend on Nasal handling this, because we're violating the MVC principle, i.e. we end up having MVC related state that does not even live in the property tree (as a matter of fact, try to properly sync/replicate any Canvas MFD across multiple fgfs instances, and you will see for yourself that we're creating tons of features that no longer scale, i.e. that are mutually incompatible with use-cases that end-users do care about, e.g. multi-instance FSWeekend/LinuxTag or shared-control setups).
This is one of the key reasons why the nature, and excessive degree, of Nasal use by fgdata/fgaddon contributors is complicating matters for core developers wanting to re-architect FlightGear (think reset/re-init, saving session state, replay, incremental booting, modularizing fg, better threading support, getting rid of legacy OpenGL code).
Thus, from a technical standpoint, the "right" thing to do would be to provide standard interfaces so that people can work out building blocks, which we can later on profile/optimize or re-implement using more appropriate solutions (think C++, effects or GLSL) - what we're currently doing isn't scaling anymore, and it is mainly because of the way we're using Nasal to work around all sorts of limitations, of which the core group is unaware - despite those workarounds no longer being compatible with use-cases like multi-instance setups (think home cockpit builders).
Now, you may disagree with many of these points because you are able to work out all sorts of workarounds to make things happen still - but your recent comments regarding a distributed AW system are basically proving that these use-cases do matter and that we as a community have failed to provide building blocks and interfaces to allow Nasal space contributions to be developed in a fashion that is well-aligned with ongoing core developments.
As someone who is pretty familiar with the ND/MapStructure code and the Canvas system in general, I can only reiterate that we need to discourage certain ongoing coding habits and actively work towards using a development model where new features are prototyped, provided and implemented in the form of sub-classes inheriting from sc::element, sc::placement and sc::projection - once we start doing that, we are approaching a situation where we can treat MFDs, and MFD components (think pages, buttons, switches, page elements) as dedicated Canvas::elements that also support versioning and proper serialization for replication/synchronization purposes.
Otherwise we will continue to see potentially useful components, features/code (think PFD, EICAS, ND, Avidyne Entegra R9, shuttle avionics) that are hardly compatible with other use-cases/aircraft, and that are rarely reusable from a coding standpoint, short of using copy & paste and a bunch of timers and listeners (which still is the predominant practice when it comes to Nasal based features).
Besides, let's keep in mind that people have been actively considering to phase out/replace Nasal - which is why it does make sense to restrict its use, or at the very least encapsulate it - allowing Canvas features to be directly registered as sc::element sub-classes implemented in Nasal space will allow us to have our cake and eat it, at the mere cost of exposing code that is already available in C++ space, while also benefiting other use-cases - no matter if that means getting rid of the legacy HUD, legacy GUI (PUI), legacy 2D panels code or just the splash screen stuff.
Just because someone holding a PhD in maths or physics is able to work out the intrinsics of properly aligning/projecting a HUD using Nasal space workarounds, doesn't mean that other potential contributors will be able to do the same - which is also kinda confirmed by the other posting here:
Canvas arcs