Unifying the 2D rendering backend via canvas
While this article is based on considerable community feedback, there's nobody working on this currently.
Mentors: Zakalawe, TheTom, Hooray, Philosopher (get in touch to learn more)
|Note The existing menubar is a hard-coded feature implemented using PLIB/PUI which we are also hoping to get rid of eventually to help us for better portability and performance. The PUI menubar can be partially customized by editing PropertyList/XML files for adding entries and styling purposes, but is otherwise fairly inflexible and doesn't support modern widgets like checkboxes, or even just sub-menus.|
| The FlightGear forum has a
subforum related to: Canvas
|I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.
|One solution would be to port the HUD to use osgText : that’s actually somewhat doable because it’s already centralised, but rather high risk close to release.
— James Turner (Jan 15th, 2016). Re: [Flightgear-devel] Corrupted HUD / 2D panel text.
(powered by Instant-Cquotes)
at some point we need to convert the generic HUD to sue the canvas - not a job I'm looking forward too - so I'm likely to steal any ideas and pieces I can to make my life easier. If anyone who actually uses HUDs wants to help with such an effort, please get in touch with TheTom and/or Zakalawe.
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, using the Canvas subsystem as the common rendering backend. Once a standalone mode for the canvas system has been implemented, all systems making use of the canvas backend will automatically support standalone (FGPanel-analogous) rendering.
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 eventually phased out. In particular, this means that wrappers for the following systems will be added:
- HUD: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/HUD
- 2D PANEL: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit
- GUI: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/GUI/FGPUIDialog.cxx#l709 (currently in progress, see Canvas Widgets)
Note that the API-requirements will be pretty much identical for GUI widgets and MFD-screens with touch screen functionality, both features will need a way to deal with keyboard/mouse input.
Initially, the main focus will be on providing the infrastructure to enable people to develop widgets entirely in Nasal space. Once that is working, it will be possible to increasingly re-implement native PUI widgets in Canvas/Nasal space, so that PUI usage is increasingly reduced.
To ensure that the Canvas/GUI wrapper is flexible enough, we need to take a look at existing hard coded PUI dialogs/widgets, and make sure that these can be theoretically reimplemented using Canvas/Nasal, and add any missing hooks as required:
- property list widget: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/GUI/property_list.cxx
- waypoint list widget: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/GUI/WaypointList.cxx
- map widget: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/GUI/MapWidget.cxx
Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded od_gauge instruments, such as:
- dclgps: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/dclgps.cxx
- kln89: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/KLN89
- groundradar: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit/groundradar.cxx
- wxRadar: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit/wxradar.cxx
- agradar: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit/agradar.cxx
- TCAS: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Instrumentation/tcas.cxx
- NavDisplay: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Cockpit/NavDisplay.cxx
We need to take a look at these instruments and their C++ code, to ensure that the Canvas API is sufficiently customizable to implement these and similar instruments purely in scripting space.
As of 07/2012 the navdb (including airports, runways etc) is fully exposed as part of the NasalPositioned module in $FG_SRC/Scripting: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Scripting/NasalPositioned.cxx.