20,741
edits
Talk:CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→View Creation API
(→Performance musings: new section) |
|||
| Line 46: | Line 46: | ||
If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST) | If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST) | ||
Update 12/2020: I played a little with such a scheme and it's actually working nicely, the basic idea is this: | |||
* one fgcommand to load an arbitrary PropertyList/XML file into a sub-tree (global tree or private one) | |||
* one fgcommand to process such a sub-tree and look for key/value pairs to define the pipeline/view | |||
* one fgcommand to optionally alias that tree or set up listeners for "live" values for dynamic views | |||
With this sort of scheme, a compositor (or a scenegraph, view) can be optionally specified in the form of: | |||
* a file on disk | |||
* a property tree hierarchy in the global tree set up from Nasal/telnet etc | |||
* an aliased sub-tree of a higher-level fgcommand or CanvasView element | |||
And it would be also possible to reload a spec on demand (if needed).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 15:56, 6 December 2020 (EST) | |||
<hr> | <hr> | ||