20,741
edits
Canvas troubleshooting: Difference between revisions
Jump to navigation
Jump to search
→Useful C++ changes
| Line 215: | Line 215: | ||
=== making Map::update() smarter === | |||
{{FGCquote | |||
|1= the canvas::map mode actually knows current range, ref lat/lon and heading - in other words, it could be a little faster by checking the ratio of pixels vs. position change - to have some update() threshold and not update things that have not changed significantly enough to be visible to the user - just imagine the ND at 320 nm showing airports: even when flying at >= 400 nm, it would not need to redraw everything at frame rate. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=193857#p193857 | |||
| title = <nowiki>Re: How to display Airport Chart?</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Nov 11th, 2013 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= Another thing that would work is coming up with a "pixel-threshold" to skip updates that are not even visible - I think TheTom mentioned that also once - currently, the Map::update() method will basically run the equivalent of a foreach loop to update each "symbol" (lat/lon), without taking into account the resolution of the map, the visibility of the element or the map's resolution. | |||
It isn't unlikely that this would be a simple optimiation to skip updates/redrawing - and when it does redraw, the projection code could be changed to use memoization/caching, i.e. a std::map<> lookup table for different std::pair<latitude, longitude> to return the matching x/y screen positions - which would mean that the cache would be populated quickly, so that redundant computations can be skipped. | |||
Note that this would be in line with the recent PagedLOD/AI work, where the size of the AI object in screen pixels determines if it to be rendered or not. | |||
Equally, an element having a bounding box of x*x does not necessarily need to be updated if its position only changed by 10% its visible size | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275639#p275639 | |||
| title = <nowiki>Re: Route Manager consumes a lot of Frame Rate</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Feb 10th, 2016 | |||
}} | |||
}} | |||
=== Adding support for wireframe mode === | === Adding support for wireframe mode === | ||
To enable wireframe mode, we only need to change the osg::StateSet accordingly. Internally, each Canvas element contains a <code>osg::MatrixTransform</code>[http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00494.html] node - there's a virtual method <code>getOrCreateStateSet()</code> exposed returning the StateSet for each element, so that we can directly it: | To enable wireframe mode, we only need to change the osg::StateSet accordingly. Internally, each Canvas element contains a <code>osg::MatrixTransform</code>[http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00494.html] node - there's a virtual method <code>getOrCreateStateSet()</code> exposed returning the StateSet for each element, so that we can directly it: | ||