Howto:Canvas Path Benchmarking: Difference between revisions

Line 4: Line 4:


== Background ==
== Background ==
One present-day perfomance property tree-writte bottleneck would be complex canvas instruments - take any of the Shuttle displays which shows roughly a hundred sensor readings each, and there's nine of those. That in the worst case means fetching roughly 900 properties from the FDM, converting them to whatever units and strings we want to display and writing them again to the tree for canvas. Combine with the ADI ball which renders a 2d projection of a 3d shape, adding another number of the same order of magnitude to write. If we'd do a naive update 'all in one frame', you'd see the bottleneck, the only reason you don't is that we fetch and update staggered. There's a handful of other cases in AW where property I/O is a bottleneck and I've worked around it. <ref>{{cite web
One present-day perfomance property tree-writte bottleneck would be complex canvas instruments - take any of the Shuttle displays which shows roughly a hundred sensor readings each, and there's nine of those. That in the worst case means fetching roughly 900 properties from the FDM, converting them to whatever units and strings we want to display and writing them again to the tree for canvas. Combine with the ADI ball which renders a 2d projection of a 3d shape, adding another number of the same order of magnitude to write. If we'd do a naive update 'all in one frame', you'd see the bottleneck, the only reason you don't is that we fetch and update staggered. There's a handful of other cases in AW where property I/O is a bottleneck and Thorsten had to  work around it. <ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35517837/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35517837/  
   |title  =  <nowiki> Re: [Flightgear-devel] Explicit recursive listeners </nowiki>  
   |title  =  <nowiki> Re: [Flightgear-devel] Explicit recursive listeners </nowiki>