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

From FlightGear wiki
Jump to navigation Jump to search
(Switch to {{flightgear source}} and {{flightgear url}} to fix the broken Gitorious links. Some file paths have been updated to their new positions.)
Line 69: Line 69:
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:  
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://gitorious.org/fg/flightgear/trees/next/src/Instrumentation/HUD
* HUD: {{flightgear url|src/Instrumentation/HUD}}
* 2D PANEL: https://gitorious.org/fg/flightgear/blobs/next/src/Cockpit/
* 2D PANEL: {{flightgear url|src/Cockpit}}
* GUI: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/FGPUIDialog.cxx#line709 (currently in progress, see [[Canvas Widgets]])
* GUI: {{flightgear url|src/GUI/FGPUIDialog.cxx|line=709}} (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.
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.
Line 80: Line 80:
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:
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://gitorious.org/fg/flightgear/blobs/next/src/GUI/property_list.cxx
* property list widget: {{flightgear url|src/GUI/property_list.cxx}}
* waypoint list widget:  https://gitorious.org/fg/flightgear/blobs/next/src/GUI/WaypointList.cxx
* waypoint list widget:  {{flightgear url|src/GUI/WaypointList.cxx}}
* map widget: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/MapWidget.cxx
* map widget: {{flightgear url|src/GUI/MapWidget.cxx}}


Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded [https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/od_gauge.cxx od_gauge instruments], such as:
Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded {{flightgear source|src/Cockpit/od_gauge.cxx|text=od_gauge instruments}}, such as:


* dclgps: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/dclgps.cxx
* dclgps: {{flightgear url|src/Instrumentation/dclgps.cxx}}
* kln89: https://gitorious.org/fg/flightgear/trees/next/src/Instrumentation/KLN89
* kln89: {{flightgear url|src/Instrumentation/KLN89}}
* groundradar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/groundradar.cxx
* groundradar: {{flightgear url|src/Cockpit/groundradar.cxx}}
* wxRadar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/wxradar.cxx
* wxRadar: {{flightgear url|src/Cockpit/wxradar.cxx}}
* agradar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/agradar.cxx
* agradar: {{flightgear url|src/Cockpit/agradar.cxx}}
* [[TCAS]]: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/tcas.cxx  
* [[TCAS]]: {{flightgear url|src/Instrumentation/tcas.cxx}}
* NavDisplay: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/NavDisplay.cxx
* NavDisplay: {{flightgear url|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.
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://gitorious.org/fg/flightgear/blobs/next/src/Scripting/NasalPositioned.cxx
As of 07/2012 the navdb (including airports, runways etc) is fully exposed as part of the NasalPositioned module in $FG_SRC/Scripting: {{flightgear url|src/Scripting/NasalPositioned.cxx}}.

Revision as of 08:49, 9 March 2016

Note: While this article is based on considerable community feedback, there's nobody working on this currently.
So if you'd like to help in one way or another, please get in touch or just help improve the article in the meantime!
Useful Skills:
PropertyList XML File, Property Tree, Nasal scripting, Canvas, README.xmlpanel, README.gui, README.layout, 2D panel code


People:

Mentors: Zakalawe, TheTom, Hooray, Philosopher (get in touch to learn more)
It's possible that this article hasn't been updated in a while, so to catch up with the latest developments, you are advised not to start working on anything directly related to this without first coordinating your ideas with fellow FlightGear contributors using the FlightGear developers mailing list or the FlightGear forums.

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.

As of 09/2014, this feature is in the process of being ported to Canvas, for details please check out Howto:Making a Canvas Menubar.


Background

Cquote1.png the reason we still havent moved to opengl 3.x+ has been due to supporting OSX. If we wish to support OSX, we need to completely abandon the fixed function pipeline. Some of our dependencies (plib) are no longer maintained , so must be replaced with something that supports shaders (canvas, etc).


Apple has made app developers to move on or stay in fixed fn. We aren't there yet.

Almost every feature in fg needs a maintainer. Maybe someone who especially loves deferred rendering will step up, and begin migrating Thorsten's als shaders to rembrandt.


— psadro_gm (Sat Oct 18). Re: Orbital Makes the Sky Black.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png the other issue is that there's still legacy GL code running in the main/rendering loop that prevents us from using a more recent OpenGL version, such as the panel/HUD and GUI code - those things are in the process of being unified, and re-implemented, on top of modern OSG code using a shared back-end via Canvas.
— Hooray (Sat Oct 18). Re: Orbital Makes the Sky Black.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code.

With the Canvas system every type of widget would be possible, so that also things like submenus can be realized.

Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats.
Cquote2.png
Cquote1.png using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays...
Cquote2.png
Cquote1.png 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.
Cquote2.png
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 newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.
Cquote2.png
Cquote1.png Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)
Cquote2.png
Cquote1.png 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)
Cquote2.png


Planning

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[1].

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:

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:

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

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.