20,741
edits
FlightGear Newsletter May 2014: Difference between revisions
Jump to navigation
Jump to search
m
→Canvas Performance
| Line 14: | Line 14: | ||
=== Canvas Performance === | === Canvas Performance === | ||
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: | 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 is a new technology, and it not just a single technology, it's built on top of other technologies, like the | Canvas is a new technology in FlightGear, and it not just a single technology, it's built on top of other technologies, like the [[Property Tree]], ShivaVG/OpenVG, OSG and OpenGL. As you may have noticed, we didn't even mention [[Nasal]] yet - that's because Nasal scripting, strictly speaking, isn't even required to use [[Canvas]] - the whole thing can be used without touching any Nasal - just by using the property tree, the built-in httpd or even the [[Telnet usage|telnet]] interface. | ||
In theory, you could create a canvas just by setting properties, and even add placements (GUI/scenery/aircraft) by doing just that. | |||
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). | |||
But whenever we've seen dead-slow Nasal/Canvas code it was usually not the problem of Nasal or Canvas per se, but due the original code/implementation in the first place, including our own code by the way :D | |||
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. | |||
For example, the very first version of the airport selection dialog was much slower than necessary, simply because it would redraw stuff unnecessarily, and not even use separate layers for different features like airports, taxiways, runways etc. | For example, the very first version of the airport selection dialog was much slower than necessary, simply because it would redraw stuff unnecessarily, and not even use separate layers for different features like airports, taxiways, runways etc. | ||
Since then, we've learned a lot about using Canvas properly, but also the combination of Nasal and Canvas, including other subsystems. | Since then, we've learned a lot about using Canvas properly, but also about the combination of Nasal and Canvas, including other subsystems. | ||
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. | 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. | ||
| Line 30: | Line 34: | ||
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. | 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. Typically, that really only applies to core developers still, or fgdata committers who have extensively worked with both, Nasal and Canvas. | 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. | ||
To use Nasal and Canvas properly, there are several layers that need to be understood, such as: | To use Nasal and Canvas properly, there are several layers that need to be understood, such as: | ||
| Line 40: | Line 44: | ||
# OpenGL | # OpenGL | ||
Most people really only understand #1 (partially), even though writing really fast code may very well involve looking at several layers in combination to see how they affect each other. | Most people really only understand #1 (well, partially), even though writing really fast code may very well involve looking at several layers in combination to see how they affect each other. | ||
So writing "fast" Nasal/Canvas code still is quite an undertaking despite things being accessible from scripting space these days. | So writing "fast" Nasal/Canvas code still is quite an undertaking despite things being accessible from scripting space these days. | ||
Which is exactly the point of having [[MapStructure]] and the [[NavDisplay]] frameworks: those are designed to handle things efficiently, e.g. by using smarter queries, smarter updates, and techniques like caching or selective/delta searches. | Which is exactly the point of having [[MapStructure]] and the [[NavDisplay]] frameworks: those are designed to handle things efficiently, e.g. by using smarter queries, smarter updates, and techniques like caching or selective/delta searches. | ||
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. | |||
Very fast Nasal/Canvas code will typically do very little at runtime/frame rate, but instead use pre-created data structures and dynamically toggle canvas layers on/off (show/hide groups) and update the underlying data selectively, while using cached images instead of lots of OpenVG paths. | Very fast Nasal/Canvas code will typically do very little at runtime/frame rate, but instead use pre-created data structures and dynamically toggle canvas layers on/off (show/hide groups) and update the underlying data selectively, while using cached images instead of lots of OpenVG paths. | ||
| Line 50: | Line 56: | ||
We've arrived at these conclusions based on testing and lots of profiling. | We've arrived at these conclusions based on testing and lots of profiling. | ||
Frame rates >= 60 fps are not impossible to achieve like this - but coding such a design is obviously much more involved than simply drawing/updating once per frame, which people will typically do. This is very similar to people running timer callbacks at frame rate instead of use using split-frame loops or listeners to do certain computations and processing selectively. A simple design can get you only so far, but an efficient design requires much more thinking. | Frame rates >= 60 fps are not impossible to achieve like this - but coding such a design is obviously much more involved than simply drawing/updating once per frame, which people will typically do. This is very similar to people running timer callbacks at frame rate instead of use using split-frame loops or listeners to do certain computations and processing selectively. A simple design can get you only so far, but an efficient design requires much more thinking, and time to get right. | ||
For instance, D-LEON has done quite some Nasal/Canvas benchmarking and confirmed that MapStructure/Canvas are sufficiently fast already (and we're still exploring additional options for making it even faster). Also, we're looking into augmenting/re-implementing certain features through native code additions, such as having dedicated extension functions, Nasal library functions or new Canvas extensions to make things even faster. | For instance, D-LEON has done quite some Nasal/Canvas benchmarking and confirmed that MapStructure/Canvas are sufficiently fast already (and we're still exploring additional options for making it even faster). Also, we're looking into augmenting/re-implementing certain features through native code additions, such as having dedicated extension functions, Nasal library functions or new Canvas extensions to make things even faster. | ||
| Line 69: | Line 75: | ||
As mentioned elsewhere, if we could have had a look at the Avidyne code it would have been a great/better foundation for MapStructure and the ND framework - but we had to work off a completely different code base (several actually), so things are a little inconsistent and less elegant - but those frameworks are '''really''' designed to be generic, not just intended to be used with different aircraft, but also different GUI dialogs. And whenever we add a new optimized feature, all people/aircraft/dialogs using those frameworks will benefit automatically (backward compatibility is handled by US). | As mentioned elsewhere, if we could have had a look at the Avidyne code it would have been a great/better foundation for MapStructure and the ND framework - but we had to work off a completely different code base (several actually), so things are a little inconsistent and less elegant - but those frameworks are '''really''' designed to be generic, not just intended to be used with different aircraft, but also different GUI dialogs. And whenever we add a new optimized feature, all people/aircraft/dialogs using those frameworks will benefit automatically (backward compatibility is handled by US). | ||
We literally depend on having many different use cases and front-end scenarios, i.e. for these two frameworks to evolve properly, we need many different aircraft developers to adopt them, do regular testing and provide feedback - and GUI use-cases are just as important. In fact, just for the sake of generalizing things, both frameworks contain support for being not just driven by the main/FDM aircraft, but even by AI aircraft. | |||
Technically, MapStructure layers are a bit more sophisticated than having pre-created SVG/OpenVG groups, because symbols can be cached in a separate canvas via a texture map, so that there's true "instancing" support for each cached symbol. This is something that we've been working on in the last two weeks. Also, positioned queries are handled by an abstraction layer to ensure that things are sufficiently fast using selective delta-updating. Besides, the ND/MapStructure code is intended to be reusable. | Technically, MapStructure layers are a bit more sophisticated than having pre-created SVG/OpenVG groups, because symbols can be cached in a separate canvas via a texture map, so that there's true "instancing" support for each cached symbol. This is something that we've been working on in the last two weeks. Also, positioned queries are handled by an abstraction layer to ensure that things are sufficiently fast using selective delta-updating. Besides, the ND/MapStructure code is intended to be reusable. | ||