Talk:Hackathon Proposal: CompositeViewer and Canvas
FWIW, I don't seem to recall seeing any performance issues back when we were prototyping the original CanvasView element. However, that was obviously not using CompositeViewer (single window/GC). In general slave cameras are cheaper, and at least for static cameras or those fixed to an aircraft (exterior views like tail/gear/FLIR etc), they might still be preferable?
In fact, CompositeViewer is usually needed whenever we have an *independent* entity (where object A may see a completely different part of the scene than object B, so that B may no longer get access to the PagedLOD nodes that A discarded already), but if the camera can be "slaved" to a parent object in the scene, that's probably what should be done? Looking at osgcompositor.cpp, it can combine both kinds of cameras at runtime.--Hooray (talk) 09:53, 16 November 2020 (EST)
- Not sure whether this relevant, but Fernando said that Canvas uses scene-graph cameras, and it seemed that the use of scene-graph cameras caused some issues with canvas-view, but it would be quite a lot of work to change canvas to use slave cameras?
- scene graph cams basically means that canvas based scenes are rendered "redundantly", that's true regardless of Comp/CV. And an obvious optimization for a number of canvas heavy aircraft (think shuttle, airliners). For full context, refer to these comments Post_FlightGear_2020.2_LTS_changes#Canvas:
- Review Tim's original suggestion: Another [Canvas] optimization is to use a pre-render camera that isn't in the scene graph to do the Canvas rendering. Otherwise the Canvas textures are rendered at least twice, in the near and far cameras.  Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft, since within each camera pass (far camera, near camera), all the passes of a technique are run. Also, Mathias stated once: that it would be good to be able to specify a completely different scenegraph in some subcameras, i.e. for having panel like instruments on an additional screen/display for example.
btw, the canvas-view based approach makes it possible to prototype things without needing to edit an aircraft and without exiting/restarting FlightGear for each and every change. The original CanvasView patches simply used ~20 lines of Nasal code (via the Nasal console) to set up a Canvas GUI dialog that would add a Canvas.Image node which in turn showed the requested view. That made it possible to go through several iterations quickly (rapid prototyping), i.e. only booting up with simple aircraft (ufo), little/no scenery to get going quickly. Just mentioning this because the Post-hackathon write-up mentions some aircraft integration issues. Stuart once mentioned that he made enormous progress on the FG1000 when he adopted a similar GUI-centric workflow, without prototyping things via the -set.xml pathway.--Hooray (talk) 11:27, 16 November 2020 (EST)