Mock up Newsletter Oct 2015: Difference between revisions

The Atmospheric Light Scattering framework has received some upgrades to the rendering of unpaved runway surfaces. The effect can now be controlled in multiple ways by setting parameters for the distribution of overlay textures, allowing to generate a structure of patchy grass, or to blend the runway smoothly into the surrounding landclass. In addition, the effect maps textures to a physical size and doesn't attempt to stretch the texture across the whole runway, which makes many more details apparent.

Scenarios-via-pui2canvas.xml.png|AI scenario.xml dialog parsed/processed by pui2canvas converter

View-dialog-generated-by-canvas.png|Screen shot showing a procedurally generated Canvas dialog, based on parsing a PUI subset of view.xml

About-dialog-rendered-by-canvas.png|Screen shot showing the FlightGear about dialog procedurally created and rendered by a Nasal/Canvas parser that turns PUI/XML markup into Canvas widgets/properties. The about dialog is making heavy use of dynamic text labels using printf formatting for displaying OpenGL related info, so needs to be mapped to Nasal sprintf/getprop calls

As of 10/2015, a simple framework is being prototyped to serve as a proof-of-concept and demonstrate how existing PUI GUI dialogs can be processed by a parser written in [[Nasal]], which turns PUI/XML markup into the corresponding [[Canvas]] GUI widgets/properties.

This will enable the removal of PLIB PUI (our legacy OpenGL GUI engine), which is known for using inefficient legacy OpenGL code that is not suitable to be used in conjunction with OSG (preventing compatibility with newer OpenGL versions, as well as affecting performance-unlike Canvas which is directly using Osg::Text, Osg::Image - as well as ShivaVG for supporting OpenVG - so a Canvas-based UI engine will be much easier to support for the OSG optimizer.), and it will also let existing dialogs be supported without having to manually update/port them.

In its current form, this is not intended to be a completely functional alternative to PUI, but just intended to document the necessary steps for supporting the existing PUI dialogs (and widgets), without having to adopt an external library.  

Simple dialogs are likely to work, while more sophisticated dialogs may require some additional work, especially when it comes to layouting and styling (including PUI themes).

This extra work would typically involve extending or creating custom Canvas widgets for wrapping PUI widgets, and integrating those with the parser shown below.

At the time of writing, it isn't clear if this approach is going to be actually used anywhere-but that doesn't really matter, because the parser is fairly straightforward and simple, which makes it an excellent stress test to exercise the underlying Canvas/C++ code or use the same approach for porting other legacy GL code (e.g. 2D panels, HUDs or even just the splash screen).

Creating a Canvas property tree hierarchy for even simple PUI/XML dialogs will easily cause the creation of dozens of layout instances and hundreds of Canvas groups in the tree, many of which may have attached listeners/timers for event handling purposes. The Nasal/Property Tree overhead is fairly remarkable, and also noticeable on older systems.

So running the parser and benchmarking/[[Built-in Profiler|profiling]] FlightGear is a pretty good way to determine Canvas/Nasal related bottlenecks and come up with ideas for extending/optimizing the Canvas C++ code a little, which will be beneficial to unrelated efforts (including any aircraft/dialogs using Canvas/[[MapStructure]] based displays), but also the long-term idea to help [[Unifying the 2D rendering backend via canvas|unify the 2D rendering back-end by porting the HUD/2D panels code to use Canvas]].

* embedded nasal/close blocks (code executed prior to dialog creation, and cleanup code executed when closing the dialog)