Canvas ND framework: Difference between revisions

Jump to navigation Jump to search

Canvas ND framework (view source)

Revision as of 15:41, 4 January 2015

2,980 bytes removed ,  4 January 2015
m
→‎mapping vs. SVG animation: Canvas Animation Framework
Line 460: Line 460:
   }}
   }}
}}
}}
=== mapping vs. SVG animation ===
It would be really nice to have two sides to navdisplay.mfd: a map (your/my area) and svg ui (Gijs' and aircraft devs' responsibility) 0.o.
:  am all for supporting the two use-cases you mentioned - then again, the old code is fragile enough, so I wouldn't add to it - the main thing the old code was all about was establishing the MVC separation so that draw routines can be reused - and that's basically done, so no need to keep the old cruft around ...
: Regarding the navdisplay stuff itself - well, it's pretty much the original code still, i.e. the design is only just evolving - algorithmically, it's still not very optimized - MapStructure only helps with mapping aspects obviously.
: I was going to suggest the "SVG/element animation" separation too - but I think Gijs etc already need to handle quite a bit of re-thinking, because things are no longer as straightforward. In the long run, it will probably happen over time - especially once other things are generalized, especially for generic PFD/EICAS/CDU/EFB functionality - these would all benefit from a corresponding "symbol animation" abstraction eventually like TheTom mentioned on the forum: PFD: A common framework in the background
: Honestly, it would have been great to have such a framework to implement MapStructure on top of it - but obviously, it's a chicken/egg issue :-)
: Currently, the main danger here is that people are going to start using copy & paste again to adopt things like Gijs' PFD, like mentioned by Zakalawe: if someone provides a 'system' I'll use it but I'm not interested in writing it myself
: So the real question is if people can be convinced to team up and come up with a generic and reusable design, or follow the original PFD/ND approach instead - interestingly, most of TheTom's work in this area (MCDU/EICAS) seems pretty reusable, also outside aircraft, i.e. usable via the GUI.
After having looked at navdisplay.mfd, I think we only need to separate a few things using io.include() to make this happen automatically over time - all the 747/Boeing-specific stuff would be moved into "config" hashes and factored out of navdisplay.mfd - into something like "boeing747.nd" (navdisplay.styles for now) that would leave us with very little code remaining in navdisplay - basically a single class and a few methods with foreach loops (well, once update() has been cleaned up at least). {{Progressbar|30}}
So we would end up with a layered design like this:
* boeing.nd (config hashes via io.include)
* navdisplay (down-stripped code, aircraft-agnostic)
* MapStructure (needs no changes)
* Symbol/Animation Layer (shared with PFD, ND, CDU, EFB, would be developed/grown over time), some animations currently implemented manually in the PFD/ND code:
** rotate (heading,bearing, azimuth)
** scale
** colorize
** update text labels (font size, font type, font color)
* canvas APIs (as is)
* canvas subsystem (as is)
* OSG / Shiva (as is)


=== Misc ===
=== Misc ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/78824"

Navigation menu