Canvas properties: Difference between revisions

Jump to navigation Jump to search

Canvas properties (view source)

Revision as of 16:35, 16 October 2013

1,495 bytes removed ,  16 October 2013
m
→‎Nested/shared "multipass" Canvases: clean up & delete outdated stuff
m (→‎Vector Data Cache: link to recent discussion)
m (→‎Nested/shared "multipass" Canvases: clean up & delete outdated stuff)
Line 101: Line 101:


One would just have to decide on which instance of FG the calculations of the ECIAS and other displays should take place, but with full mounting support this should be easily distributable as computing power is available.
One would just have to decide on which instance of FG the calculations of the ECIAS and other displays should take place, but with full mounting support this should be easily distributable as computing power is available.
=== Nested/shared "multipass" Canvases ===
A while ago we talked about nested canvases, where a new "element" type could refer to an existing canvas texture, so that nested canvas hierarchies could be implemented. So that one canvas output can be used as the input for another canvas, or vice versa ("everything is a canvas").
This might be the easiest option to implement optimized displays, without using any C++:
Looking at modern aircraft like your C130J, it is fairly common to have multiple versions of the same display in the cockpit, i.e. one for each pilot/copilot and one for redundancy. These are basically identical displays, so they could use the same backend code - they usually just have different settings.
Currently, we could implement this as a separate Nasal object for each display (all using the same base class) with one canvas for each display. That would be potential wasteful and unnecessary, especially when all displays are showing the same data and using the same settings. So that's where we have optimization potential. At the C++ level that would be unncessarily complicated and inflexible though.
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.


=== Camera Views in Canvas ===
=== Camera Views in Canvas ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/63397"

Navigation menu