20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
→Images: Static Textures & Cascaded Canvases {{Done}}
| Line 104: | Line 104: | ||
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 | === 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++: | 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 | 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. | 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. | ||