Canvas properties: Difference between revisions

Jump to navigation Jump to search

Canvas properties (view source)

Revision as of 13:12, 16 August 2012

298 bytes removed ,  16 August 2012
→‎Images: Static Textures & Cascaded Canvases {{Done}}
Line 83: Line 83:
=== Images: Static Textures & Cascaded Canvases {{Done}} ===
=== Images: Static Textures & Cascaded Canvases {{Done}} ===
Status: http://gitorious.org/fg/flightgear/commit/310ddbf8c5bfd6807eac79fb9cf22f6801bb80ad
Status: http://gitorious.org/fg/flightgear/commit/310ddbf8c5bfd6807eac79fb9cf22f6801bb80ad
We talked about supporting static textures via file names and handling them via OSG, it just occurred to me that it would be pretty powerful to support two more features
providing a hook to get a binary dump of the a canvas texture (i.e. as a PNG file)
providing a hook to use another canvas as the input for an image file name in another canvas group
Basically, this would make it possible to recursively use a canvas as the input for another canvas.
And by adding a hook to access the texture of the canvas as a binary dump, Nasal scripts could not only write a canvas texture to the file system, but they could even mime-encode it and send it to the browser (via the built-in HTTP server), so that canvas textures could be shown inside the browser for example, basically canvas textures could be used outside the fgfs process by providing a handle to access the dump.
These two features alone would make it possible for people to draw to a canvas, save it to the file system and even chaining canvases by using the output of one canvas, as the input for another one (a while ago, we talked about the lack of support for chaining od_gauge systems).
And serializing a canvas is trivial because it's just a property tree, so it can be done via save_properties()


Another use case would be this:
Another use case would be this:
Line 126: Line 113:


Now, if we had support for cascading canvases, then we could implement the Nasal base class such that it shares a single canvas base texture, and merely applies a different context of "settings" for each instrument. This would mean that even rendering 100x the same instrument with different data/settings, we would just have a single "shared" canvas texture.
Now, if we had support for cascading canvases, then we could implement the Nasal base class such that it shares a single canvas base texture, and merely applies a different context of "settings" for each instrument. This would mean that even rendering 100x the same instrument with different data/settings, we would just have a single "shared" canvas texture.
=== Serializing a canvas to a buffer or file ===
providing a hook to get a binary dump of the a canvas texture (i.e. as a PNG file)
By adding a hook (Nasal extension function) to access the texture of the canvas as a binary dump, Nasal scripts could not only write a canvas texture to the file system, but they could even mime-encode it and send it to the browser (via the built-in HTTP server), so that canvas textures could be shown inside the browser for example, basically canvas textures could be used outside the fgfs process by providing a handle to access the dump.
These two features alone would make it possible for people to draw to a canvas, save it to the file system and even chaining canvases by using the output of one canvas, as the input for another one (a while ago, we talked about the lack of support for chaining od_gauge systems).
And serializing a canvas is trivial because it's just a property tree, so it can be done via save_properties()


=== Element/Group Defaults ===
=== Element/Group Defaults ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/53040"

Navigation menu