20,741
edits
FlightGear Newsletter July 2012: Difference between revisions
Jump to navigation
Jump to search
m
→Adopting the new Canvas 2D rendering system
| Line 10: | Line 10: | ||
As of July 2012, FlightGear core developers agreed to adopt Tom's new [[Canvas]] 2D rendering system which is purely property-driven and handles all [[Original Canvas Proposal|2D drawing via the FlightGear property tree]]. Initially, the idea will be to replace the current GUI toolkit (PUI/PLIB, which has shown many limitations over time) and use a purely [[Canvas]]-based implementation instead, which will be mostly implemented in scripting space using Nasal and merely use the Canvas system as its rendering backend. The implementation details are covered at [[Canvas Widgets]]. | As of July 2012, FlightGear core developers agreed to adopt Tom's new [[Canvas]] 2D rendering system which is purely property-driven and handles all [[Original Canvas Proposal|2D drawing via the FlightGear property tree]]. Initially, the idea will be to replace the current GUI toolkit (PUI/PLIB, which has shown many limitations over time) and use a purely [[Canvas]]-based implementation instead, which will be mostly implemented in scripting space using Nasal and merely use the Canvas system as its rendering backend. The implementation details are covered at [[Canvas Widgets]]. | ||
This step will make it eventually possible for end users to easily customize the FlightGear GUI and its appearance by creating custom GUI styles (themes/skins), but also by creating completely new GUI widgets using an SVG editor like Inkscape. | This step will make it eventually possible for end users to easily customize the FlightGear GUI and its appearance by creating custom GUI styles (themes/skins), but also by creating completely new GUI widgets using an SVG editor like Inkscape. | ||
Currently (07/2012) only drawing inside an existing (PUI) dialog is possible, but the idea is to slowly implement the current functionally in Nasal and get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard interaction with Nasal will be needed. | |||
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. | |||
The point of the canvas widget demo is to demonstrate how powerful and flexible the new canvas system really is, i.e. it cannot just be used for aircraft scripting (instruments, MFDs), but also for GUI scripting - which means that using the canvas system would unify the 2D rendering backend (all can be handled via canvas), while reducing the amount of C++ code we have doing these things, which would mean that the GUI system could be entirely maintained in scripting space, i.e. as part of the base package, by people who don't need to know C++ - some basic Nasal knowledge will do. | |||
Basically, adopting the new canvas system for such and similar purposes, will mean that tons of old/oudated C++ code can be phased out and replaced by a single consistent implementation in C++, that is using modern C++/OSG code - which ultimately also means that OSG itself can make more assumptions about what's being rendered, so that more optimizations (= better frame rates) can be more easily accomplished by using OSG coding patterns and protocols, instead of outdated/custom/3rd party libraries which would need to be manually baked into the existing FG/SG/OSG eco system. | |||
Now what's cool about the canvas system is that it's integrated in such a fashion that it will keep working with the old GUI code still in place.In addition, all of the exsting GUI features (layouting, XML processing) are implicitly supported due to the way the canvas system is implemented. These are real roadblocks when implementing a new GUI library next to PUI, because all of the existing stuff would need to be explicitly ported (either in C++ space or by converting tons of XML files). | |||
Overall, the canvas system will give us all of this "for free", and it will mean less C++ code in the source tree, too - i.e. better maintainability. | |||
Also, once the standalone [[FGCanvas]] becomes available, it would also be possible to run the GUI in multiple windows or even in separate processes. | |||
In addition, by using the canvas system for GUI widgets, it would also be possible to render aircraft instruments, MFDs, HUDs etc '''inside''' GUI dialogs, too. | |||
{{#ev:youtube|CIS8UyuJLgM}} | {{#ev:youtube|CIS8UyuJLgM}} | ||