Canvas properties: Difference between revisions

{{Template:Canvas Navigation}}

* FlightGear core: A basic canvas for drawing texts and paths (polygons and curves) has been merged. (see  merge requests [https://gitorious.org/fg/flightgear/merge_requests/26 26] and [https://gitorious.org/fg/flightgear/merge_requests/30 30])

Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.

[[File:Cessna 172P Canvas Demo.png|380px|thumb|Demonstration of the new Canvas drawing API on the Cessna 172P.]]

# Get the Nasal API and demonstration code from the [https://gitorious.org/fg/fgdata/merge_requests/150 fgdata/merge request] (See at the bottom of the merge request pages for details)

# Observe a nice display in front of you with some animated text elements

# If it doesn't look like the picture on the right please report a bug (As comment on the merge request or on the Talk page)

# And if it works try out modifying the demo, integrate it into new planes, report more bugs and give me some feedback :)

* ''fgdata/Nasal/canvas/api.nas'' (Contains the implementation of the API)

* ''fgdata/Aircraft/Instruments-3d/canvas-test/canvas-test.nas'' (Demonstrates how to use the API)

* Support drawing to textures for aircraft instruments (supported already)

* Support drawing to aircraft HUDs (supported already)

* Static image files should be handled like any other element on the canvas. Only instead of specifying a path you'll have to set the file system path to an image which will be loaded with osg.

This section lists a bunch of ideas related to supporting Canvas textures for GUI drawing needs, i.e. to render Canvases as textures, but also to increasingly implement parts of the GUI (such as custom widgets) using interactive Canvases with scripted callbacks, the idea is to work around existing GUI/PUI shortcomings by using Canvases to implement custom styles and widgets.

* '''TheTom''': "Maybe it would be good not to create a canvas for each widget but instead for each window. I don't know what the performance impact is with using many cameras and lots of separate textures, but probably the GPU won't like it very much."

Objective: Brainstorming of all ideas related to fgpanel-related functionality for the new Canvas subsystem

Some more ideas have been collected here: [[SGModule - standalone SGSubsystems]].

'''TheTom''': I already have some experimental code for an old version of the canvas. But basically it is just mapping the xml structure to the property tree. I though have no plans to support the full SVG standard, but only a subset. Maybe we should implement this in Nasal so its easier to add suport for new SVG features if someone needs it. As there is already support for parsing xml in Nasal parsing SVG should be pretty straight forward. Just a boring programming exercise :-) But using separate canvas elements instead of a single image will always be slower as every little piece of the canvas hat to be triangulated and afterwards rendered every time the canvas gets updated instead of just copying an image. On the other hand you if you use the canvas you can dynamically update the contents of the image and also get (theoretically) unlimited resolution, even changeable at runtime.

A short video demonstrating a possible usecase (C-130J AMU):

{{#ev:youtube|_oRX53JyXmM}}

'''Hooray''': We need to come up with some simple interface, so that the created texture can be used in another system.

Specifically, thinking in terms of other od_gauge instruments at the moment:

:: '''Hooray''': Yes, that would be the cleanest and most flexible solution. I think James already mentioned that he's planning to reuse your canvas code in other hard-coded instruments (see the merge request discussion).Instead of issuing raw OpenGL/OSG drawing commands in the subsystem, all of them would need to use your canvas instead.

'''Important''': All of the following sections predate the existing implementation, and as such they are really only kept for reference here.  

{{cquote|What we will need is some cairo/glitz like 2d api to draw the HUD and do some MFD's. I believe that this is even more apprioriate for such rendering areas like issuing raw OpenGL commands. With such an abstraction we are open to map that to an immediate more rendering pass to a texture or if this is used to build up a part of the scenegraph in case we do not have RenderTexture available. [...] Also Camera nodes must be accessible from within flightgear. Whenever we need an other direct access to the scenegraph we can extend the abstraction layer.| (Mathias Fröhlich) FlightGear Devel mailing list<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05396.html |title=HUD: raw gl-commands vs. plib/osg wrappers |author=Mathias Fröhlich |date=29 July 2006 }}</ref>}}

Many of the previous discussions focus on a specific use case scenario for introducing a 2D drawing API to FlightGear, namely that of adding 2D drawing support for scripting glass cockpit functionality.  

* "What we will need is some cairo/glitz like 2d api to draw the HUD and do some MFD's. I believe that this is even more apprioriate for such rendering areas like issuing raw OpenGL commands. With such an abstraction we are open to map that to an immediate more rendering pass to a texture or if this is used to build up a part of the scenegraph in case we do not have RenderTexture available."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05396.html]

* "Although the FlightGear design fairly modular it's provided as a single binary.Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22673.html]

* "IMHO the one important threading benefit is if we could get all of the rendering off the main simulation loop, meaning that the model runs independent of the presentation."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22935.html]

* "I guess I'm thinking about how FG is pretty monolithic and wondering how much of an over-head there might be in making it more modular. Might also be worth thinking about parallelism aspects."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg33306.html]

* "enforcing subsystems to *only* communicate via the property tree [...] it would then become possible to run any 'clean' subsystem on a pool of worker threads (maybe just one, maybe more)."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html]

Previous discussions about a 2D drawing API for FlightGear were mostly about providing such an API specifically to be accessed by the Nasal scripting interpreter (e.g. see [[FlightGear Glass Cockpits]]), this discussion instead focuses on using the FlightGear property tree as the common 2D drawing interface among FlightGear subsystems, which would make the 2D drawing API accessible to any FlightGear subsystem (including Nasal) or even external programs accessing FlightGear's property tree, while only adding a very small layer of indirection.

* allow nested hierarchies of "drawable" nodes, to draw complex shapes - each "drawable" may be composed of other drawables

* provide property tree driven "render to texture" support: create, modify and delete textures using properties

* generic enough to be usable by aircraft panels, GUI dialogs or scenery elements

* allow for a high degree of configurability and customization (e.g. support styling of individual elements like CSS) by end users

"Canvas properties" would be conventional properties, the only difference being that a certain structure and hierarchy is internally expected to make them valid, so that they can be used to dynamically render to textures.

Once a drawable (or any of its child nodes) is modified, the drawable would be marked as "dirty" to trigger an update.

Using property listeners, provide support for drawing basic primitives (i.e. points, lines, rectangles, circles) to dynamically created and updated textures by setting properties in a dedicated branch of the property tree.

This proposal integrates well with previously discussed plans to make FlightGear more modular by leveraging its property tree to handle IPC among all subsystems and related external programs.

While this adds a thin layer of indirection, it has many advantages:

* parametrization of drawables would make it possible to "derive" from a drawable (i.e. a VOR symbol) and customize it (e.g. by changing the color or size)

* Point (x,y)

* Line (x1,y1 - x2,y2)

* Text (string)

* [[Howto: Create a 2D drawing API for FlightGear]]

[[Category:Property Tree]]