20,741
edits
Talk:CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
→Performance musings: new section
m (BTW: we already have SGPropertyNode based inheritance in simgear) |
(→Performance musings: new section) |
||
| Line 64: | Line 64: | ||
:: That sounds very much like the way Nasal's "multiple-inheritance" mechanism is internally implemented (it traversing a vector named "parents") - while it sounds indeed very powerful, it seems like overkill at this point ? Personally, I'd opt for a simple "version" argument for views (XML + property level) - so that new features can be easily added without breaking anything, if aircraft devs want to use those, it's not too much specify a corresponding <code><version>112</version></code> tag or a corresponding props.Node and increment the version number whenever breaking changes are made to sview, while posting an announcement to the devel list. That would also mean that scripts could be provided to update -set.xml files automatically. BTW, it only just occurred to me that there is already similar SGPropertyNode machinery in simgear/material/Effect.cxx, Tim once implemented effects-inheritance via XML/property trees that way, so you may want to take a look if you're interested in that approach (if in doubt ask Fernando for a more specific pointer). Personally, I think it's more important to expose some dedicated fgcommand tooling to create views from scratch, so that we can run some tests (stability, performance) and maybe get others to stress-test the CV mode. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:59, 4 December 2020 (EST) | :: That sounds very much like the way Nasal's "multiple-inheritance" mechanism is internally implemented (it traversing a vector named "parents") - while it sounds indeed very powerful, it seems like overkill at this point ? Personally, I'd opt for a simple "version" argument for views (XML + property level) - so that new features can be easily added without breaking anything, if aircraft devs want to use those, it's not too much specify a corresponding <code><version>112</version></code> tag or a corresponding props.Node and increment the version number whenever breaking changes are made to sview, while posting an announcement to the devel list. That would also mean that scripts could be provided to update -set.xml files automatically. BTW, it only just occurred to me that there is already similar SGPropertyNode machinery in simgear/material/Effect.cxx, Tim once implemented effects-inheritance via XML/property trees that way, so you may want to take a look if you're interested in that approach (if in doubt ask Fernando for a more specific pointer). Personally, I think it's more important to expose some dedicated fgcommand tooling to create views from scratch, so that we can run some tests (stability, performance) and maybe get others to stress-test the CV mode. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 19:59, 4 December 2020 (EST) | ||
== Performance musings == | |||
Based on the "research" looking through osg-users, here are some observations: | |||
* for the time being it might make sense to force single threaded mode when the CompositeViewer is running | |||
* in single-threaded mode, and CullDrawThreadPerContext, thread handling (stop/start) is NOT needed and gives better performance (we could use an line function or a macro here) | |||
* for the list of views that people can cycle through, it might make sense to set up those already during initialization and simply hide the camera via setNodeMask(0x0), this should tell the PagedLOD/DatabasePager to keep the corresponding tiles in memory so that the initial delay when cycling between views might be fixed | |||
* for starters, we might want to create a single GraphicsWindow and then share this between all our Views, and maybe set up the equivalent of a "WindowBuffer" (or pool) with invisible windows to reduce the initialization overhead a little (basically setting the node mask to disable rendering and then hiding the window so that the window can be reused) | |||
* for the CanvasView use case, we may want to add an attribute to toggle DYNAMIC DataVariance on/off, i.e. to "finalize" elements and treat them as static to increase concurrency potential | |||
* for the Canvas in general: view level cams can be threaded unlike scenegraph cams, so that should probably be the very first thing to be explored before we revisit CanvasView | |||
* we probably don't want to use any context sharing for the time being | |||
--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:22, 6 December 2020 (EST) | |||