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

Jump to navigation Jump to search
Line 3: Line 3:
== Background ==
== Background ==


{{cquote|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)|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38629.html  Thomas Geymayer]}}
{{cquote|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.|[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37861.html  Thomas Geymayer]}}


{{cquote|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... |[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37867.html  Thomas Geymayer]}}
{{cquote|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... |[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37867.html  Thomas Geymayer]}}

Navigation menu