Unifying the 2D rendering backend via canvas: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 26: Line 26:
* NavDisplay
* NavDisplay


As of 07/2012 the navdb is fully exposed as part of the NasalPosition module $FG_SRC/Scripting.
As of 07/2012 the navdb is fully exposed as part of the NasalPositioned module $FG_SRC/Scripting.

Revision as of 15:41, 6 July 2012


Background

Cquote1.png The long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with never OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.
Cquote2.png


The Canvas subsystem is flexible enough to re-implement existing 2D rendering related features, such as the HUD system or the 2D panel system, in scripting space, so that legacy C++ code can be incrementally replaced with a more accessible and more maintainable version in scripting space, i.e. as part of the base package - while ensuring that the 2D rendering backend is increasingly unified, as part of the Canvas subsystem.

The idea is to provide Nasal wrappers for these systems, which implement the existing behavior using the canvas system, so that the old C++ code can be phased out. In particular, this means that wrappers for the following systems will be added:

  • HUD
  • 2D PANEL
  • GUI

To ensure that the Canvas/GUI wrapper is flexible enough, we need to take a look at existing hard coded PUI dialogs, and make sure that these can be theoretically reimplemented using Canvas/Nasal:

  • property browser
  • waypoint list dialog
  • map dialog

Also, the Canvas subsystem should be powerful enough to re-implement existing hard-coded od_gauge instruments, such as:

  • wxRadar
  • agradar
  • NavDisplay

As of 07/2012 the navdb is fully exposed as part of the NasalPositioned module $FG_SRC/Scripting.