20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Development Post 3.2: code review updates http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214252#p214252
m (→Development Post 3.2: code review updates http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214252#p214252) |
|||
| Line 324: | Line 324: | ||
== Development == | == Development == | ||
=== Post 3.2 === | |||
Gijs has already begun to clean up the update() method, and navdisplay.mfd is now back down to under 800 lines of code. Hooray will need to revisit adding support for '''switches''' (i.e. a helper class) and corresponding display modes. | |||
At that point, we can probably simplify most things easily and move them out of the mfd file. There are some opportunities to clean up navdisplay.styles by looking at identical/similar code, such as the altArc vs. altArcCtr handling, which is basically boilerplate code. We can probably reduce navdisplay.mfd down to ~500 lines, which is mainly a matter of fixing up the update() method and making the newMFD() helper more generic. | |||
Once that is the case, navdisplay.mfd should be generic enough to be also useful to help with porting the existing PFD code, because it's ultimately no longer ND specific, but simply a framework for animation SVG elements on a Canvas. Performance-wise, we can easily optimize the existing code by getting rid of the foreach() loop in update() and using exclusively listeners to selectively invoke only required predicates. | |||
That would even allow us to get rid of the maketimer() hack. A few computations could/should probably be shared by being moved to '''common''' entry and writing their results to a hash, so that other elements can reuse previous results, e.g. altRangePx, rotation angles etc - there's no need, to recompute those in each callback. On the ctor side, we may want to allow individual elements to be easily disabled or overridden, analogous to how MapStructure layers can be customized/styled and disabled. We could probably reuse the same code we're using for options/style handling here. Otherwise, there are still a few "hard-coded" getprop() references that should better use the NDSourceDriver logic, or its MapStructure equivalent, i.e. aircraftpos.controller. | |||
There are also still a few properties that should become configurable, like we once said WRT to having multiple instances of an instrument/radio etc | |||
{{FGCquote | |||
|just so that I don't forget about it: [https://gitorious.org/fg/fgdata/commit/7da1406cfbed8af69c5cefe215b4f327d791423d https://gitorious.org/fg/fgdata/commit/ ... 27d791423d]<br/> | |||
<br/> | |||
<ul> | |||
<li> append(m.listeners ........ seems a common idiom: provide either a helper method or extend the underlying base class accordingly</li> | |||
<li> WPT/RTE options should probably be exposed via the ctor, so that the ND code can override those defaults ?</li> | |||
<li> unify WPT/RTE handling for wpt num ?</li> | |||
<li> maybe provide a base class for both that encapsulates identical requirements ?</li> | |||
<li> FIX.symbol still contains hard-coded colors, should be using styling there, TFC.symbol is using hard-coded colors & font size</li> | |||
<li> navdisplay: swithcing between CTR & PLAN mode should be better supported by encapsulating setTranslation() etc</li> | |||
<li> get rid of _draw_rwy_nd() calls</li> | |||
<li> port runway-nd.draw , and support styling there</li> | |||
</ul> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214252#p214252 | |||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Jul 07</nowiki> | |||
}} | |||
}} | |||
=== mapping vs. SVG animation === | === mapping vs. SVG animation === | ||