Warty wrote:One feature that is hard to find info on in FG is the 2D panels. I'm sure someone will be along shortly to explain why they don't want you to use them. But they do still work. You can have as many or few as you want:
2D panels are basically a thing of the past, i.e. a legacy feature - however, they can still be useful for certain purposes, like you say.
Speaking in general, they're there to stay - however, there's ongoing work to re-implement the underlying back-end code to stop using legacy OpenGL code, iswhich causing problems elsewhere:
https://wiki.flightgear.org/OpenGL#Statushttps://wiki.flightgear.org/FlightGear_and_OpenGL_ESBasically, any legacy OpenGL in the main loop makes it impossible to modernize the renderer and to makes it really difficult to use a more recent version of OpenGL (let alone Vulkan), which is why FlightGear performance may sometimes "suck" in comparison to other software.
This is a challenge caused by all legacy OpenGL code, not specific to the 2D panels system (HUD, PUI GUI and some other features).
The stated long-term goal here is to unify/retarget the legacy 2D rendering back-end by making it go through the Canvas system (which is mostly using OSG internally, and for non-OSG parts (namely Canvas.Path via ShivaVG), it's at least well-encapsulated so that it can be easily updated once the need arises).
These are actually items on the official roadmap of the post-LTS release plan/development cycle, added by senior core devs:
https://wiki.flightgear.org/Post_Flight ... #2D_Panelshttps://wiki.flightgear.org/2022.X_Release_PlanThe overarching set of goals is best explained by looking at these wiki pages:
https://wiki.flightgear.org/Unifying_th ... via_canvashttps://wiki.flightgear.org/Canvas_News#2D_Panelshttps://wiki.flightgear.org/FlightGear_ ... 8OpenVG.29That being said. the 2D panels component/subsystem is being refactored (at the encouragement of James Turner) by another contributor (Gaétan Allaert), and the work can be seen/tracked here:
https://sourceforge.net/p/flightgear/fl ... uests/217/However, it is worth noting that the original designer of the Canvas system (Thomas Geymayer repeatedly discouraged people from creating Canvas trees from C++ and instead suggested to extend the existing sc::Element API and add to that, or create new/dedicated helper elements for a variety of reasons (see the devel list archives for details) - whereas the current set of patches isn't really using that approach but instead builds Canvas trees in C++ space.
At the time, Tom's thinking was that extending the Canvas system by adding to its elements (or creating new ones) would mean that the Canvas system could become self-sufficient in that these same elements could also be used to solve other problems, i.e. by simply writing a parser in scripting space to automatically retarget the HUD/2D panels system using the same set of patches, while also making sure that other people/projects using the Canvas system would benefit from these changes, i.e. without those being specific to a single use case (like the HUD or 2D panels).
Back then, this was inspired by the idea to unify all other legacy OpenGL code using the same approach, including the PUI back-end by retargeting that to use a "pui2canvas" translator (an idea repeatedly discussed between Tom and James at the time, back in 2012, i.e. almost 10 years ago).
This would have meant that the underlying Canvas system only needed to be extended to add the missing bits to support what's needed for the HUD/2D panels and a PUI runtime, while people developing avionics using the Canvas would benefit from the same enhancements - at the mere cost of maintaining 3 distinct Nasal parsers to build up the corresponding Canvas hierarchies to map supported primitives to Canvas elements.
Again, the motivation at the time was to quickly get rid of legacy OpenGL code (HUD, 2D Panels and PUI), all in one swoop.
Other than that, there's no reason why people should not continue to use the 2D panels stuff.
https://wiki.flightgear.org/Pui2canvas