20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→Static Textures & Cascaded Canvases {{Pending}}
| Line 95: | Line 95: | ||
I read about this idea somewhere on the wiki, so it was discussed previously. | I read about this idea somewhere on the wiki, so it was discussed previously. | ||
That would be a simple change, and it would help "typing" properties a little more, the extension would also be useful for other systems which deal with file names or paths, because it would be much easier to handle validation of file names and directories at the core level | That would be a simple change, and it would help "typing" properties a little more, the extension would also be useful for other systems which deal with file names or paths, because it would be much easier to handle validation of file names and directories at the core level | ||
A while ago we talked about cascading 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 the 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. | |||
=== Vector Images (Status 07/2012:SVG parser implemented and available) === | === Vector Images (Status 07/2012:SVG parser implemented and available) === | ||