Post FlightGear 2020.2 LTS changes: Difference between revisions

Jump to navigation Jump to search
m
m (→‎Canvas: strike/update obsolete items)
Line 112: Line 112:
=== Canvas ===
=== Canvas ===
{{See also|Unifying the 2D rendering backend via canvas}}
{{See also|Unifying the 2D rendering backend via canvas}}
* Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable.(Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not)<ref>https://sourceforge.net/p/flightgear/mailman/message/29608899/</ref>
* Remove the C++ HUD in favour of Canvas-based version: this requires some kind of migration script or framework, so we have at least the default UFO HUD available <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref>
* Remove the C++ HUD in favour of Canvas-based version: this requires some kind of migration script or framework, so we have at least the default UFO HUD available <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref>
* Review Tim's original suggestion<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: 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'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> 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.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref>
* Review Tim's original suggestion<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: 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'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> 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.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref>

Navigation menu