FlightGear Newsletter May 2014: Difference between revisions

Recently, it's been 2 years since [[Canvas]], our 2D rendering API got integrated. And even today, there are people claiming that aircraft using Nasal and Canvas are generally slow and don't provide sufficient performance, suggesting not to adopt Canvas yet, so here are some comments about that, to help put some context around such statements:

Canvas being a new technology, we obviously still have to learn what works and what doesn't, and often that also means finding things that are too slow for some reason. And these days, there are easily a handful of abstraction layers involved, all of which may contribute to things being too slow. And debugging/profiling isn't always straightforward, especially when several boundaries are crossed (Nasal, property tree, C++, OSG/OpenGL).

Just because there are accessible means to add scripted graphics to FlightGear doesn't mean that people automatically know how to use this technologies properly.

So, Canvas being a fairly recent feature, there's sometimes some really -sorry- stupid stuff done in various areas, that makes people think that Nasal and/or Canvas are generally slow.  

However, that is not generally true. Aircraft like the m2000-5 or the extra500 are indeed fairly slow, but not primarily because of Nasal/Canvas, but due a combination of factors, including several other FG technologies. And the 747 or 777 are slow even without any Nasal/Canvas code running, we can actually measure now how little impact our Nasal/Canvas code has, and how significant the impact is due to complex cockpit modeling (many polygons and high resolution textures). Understandably, under such circumstances, improper use of Nasal and/or Canvas may cause additional performance issues.

Anyway, nobody should simply "port/convert" stuff like -for example- the Garmin196 to use Canvas, that's exactly where all those problems come from: Canvas and Nasal themselves are simply too low-level for these purposes, people need to be very experienced to come up with "fast" code here, very familiar with FG and certain Nasal technologies like timers and listeners (or the whole process inevitably involves lots of trial & error). Typically, that really only applies to core developers still, or fgdata committers who have extensively worked with both, Nasal and Canvas over the years.

Imagine it like "Ruby on Rails" for aviation charts - that's what the whole MapStructure framework is all about: maps and charts. The NavDisplay framework also used to be fairly inefficient in its early days - since then, we've also significantly reworked it to use MapStructure. That introduced some ugly hacks because we didn't want to rewrite it completely, but now its layers are mostly using MapStructure. And most of the original ND stuff has been refactored, generalized and integrated with the MapStructure framework, so that this very code can be used in other places, not just other aircraft, but also GUI dialogs.   

But whenever someone is coming up with a custom mapping solution -solving the same problem that MapStructure and Gijs' ND frameworks solve- that doesn't use those frameworks, they need to do all the hard work from scratch, and code sharing/reuse and maintenance is made increasingly difficult, too.

Quite a few of the problems people are likely to encouter are already solved via MapStructure, i.e. identical paths for different symbols are simply instanced by using a raster image (canvas) as a cache.

Bottom line being, if there's someone who actually IS that experienced and knows how to write good Nasal/Canvas code, that person should better team up with us, to help improve the generic framework, rather than develop some niche instrument or dialog that will only ever be used by a few aircraft.