FlightGear Newsletter October 2016: Difference between revisions

(Navbar)
Line 63: Line 63:
''Continue reading at [[Howto:Prototyping a new NavDisplay Style]]…''
''Continue reading at [[Howto:Prototyping a new NavDisplay Style]]…''


=== Benchmarking Canvas Path Performance ===
=== Benchmarking Canvas path performance ===
[[File:Shuttle avionics meds pfd orbit.jpg|thumb|A screenshot of the ADI ball]]
As part of the development of the [[Space Shuttle]], Thorsten has added a [[Canvas]]-based [[Shuttle ADI ball|ADI ball]]. However, it is somewhat of a resource hog.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=297596#p297596
|title  = Re: Nasal must go
|author = Thorsten
|date  = Oct 28th, 2016
|added  = Oct 28th, 2016
|script_version = 0.40
}}</ref> As can be seen from the screenshot of it, it is very complex and involves a lot of calculations.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=297665#p297665
|title  = Re: Nasal must go
|author = Thorsten
|date  = Oct 29th, 2016
|added  = Oct 29th, 2016
|script_version = 0.40
}}</ref> However, performance tests indicate that the cause of the bottleneck is the huge amount of [[Property Tree|property]] manipulation involved during each update, ''after'' the actual calculations have been completed. This has also been shown to be a problem for any very complex Canvas.


Thorsten has done a few performance tests, and the [[Shuttle ADI ball]] at full glory is a resource hog (mainly property throughput, canvas isn't good at that kind of problem...).<ref>{{cite web
Some ways to help reduce bottlenecks include using {{func link|getprop}}/{{func link|setprop}} instead of [[Nasal library/props|props.nas APIs]] and using variables instead of properties where possible.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=289447#p289447
|url    = https://sourceforge.net/p/flightgear/mailman/message/30724363/
|title  = Re: Space Shuttle
|title  = <nowiki>Re: [Flightgear-devel] Nasal props API relative path support</nowiki>
|author = Thorsten
|author = Thorsten Renk
|date  = Aug 26th, 2016
|date  = Apr 15th, 2013
|added  = Aug 26th, 2016
|added  = Apr 15th, 2013
|script_version = 0.40  
|script_version = 0.40
}}</ref>
}}</ref>


The bottleneck is rendering the ADI-created property IO when this is at high quality if the GPU is fast enough.<ref>{{cite web
''Continue reading at [[Howto:Canvas Path Benchmarking]]…''
  |url    =  https://forum.flightgear.org/viewtopic.php?p=293165#p293165
  |title  =  <nowiki> Re: Space Shuttle </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Aug 26th, 2016
  |added  =  Aug 26th, 2016
  |script_version = 0.40
  }}</ref>
 
[[File:Shuttle avionics meds pfd orbit.jpg|left|thumb|The center portion of the ADI ball consists of the line grid which is generated by projecting a pattern of meridians and coordinate circles on a sphere into 2d space and then clipping the central portion out of it.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297665#p297665
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Oct 29th, 2016
  |added  =  Oct 29th, 2016
  |script_version = 0.40
  }}</ref>
]]
 
 
The actual bottleneck is the ADI ball canvas code, because all needs to be done in the same frame, and the ADI should be updating reasonably fast. Also, getting the properties to display is not the issue, setting the points for canvas is.
 
For the MFDs... let's go through the numbers. We have 40 pages by now, each displays on average something like 50 properties. That's 2000 getprop calls for the data provider to manage. At 3 Hz, and 30 fps, that's 200 requests per frame.
 
Now, if these 40, no more than 9 different ones can actually be on at any given time - so that's 450 getprop calls if you do it without data provider.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297596#p297596
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Oct 28th, 2016
  |added  =  Oct 28th, 2016
  |script_version = 0.40
  }}</ref>
 
Assembling a property path by string manipulation may be in theory less appealing, but it is in practice 3 to 10 times faster than using the props module (implemented in scripting space)- Thorsten has made several benchmark tests, all leading to the same result. Large-scale property manipulation from Nasal is performance hungry and should be avoided if possible by using Nasal-internal variables instead, and if it needs to be done, getprop() /setprop() offer significantly superior performance. If you dig a bit in the mailing list archive, there should be a post with the actual benchmark test results.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/30724363/
  |title  =  <nowiki> Re: [Flightgear-devel] Nasal props API relative path support </nowiki>
  |author =  <nowiki> Renk Thorsten </nowiki>
  |date  =  Apr 15th, 2013
  |added  =  Apr 15th, 2013
  |script_version = 0.40
  }}</ref>
 
In the second case the property tree is being walked trough by the C++ code while in the first case it's done in Nasal. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/26170047/
  |title  =  <nowiki> Re: [Flightgear-devel] Musings on optimizing Nasal code </nowiki>
  |author =  <nowiki> Erik Hofman </nowiki>
  |date  =  Sep 15th, 2010
  |added  =  Sep 15th, 2010
  |script_version = 0.40
  }}</ref>
 
[[File:Canvas-path-benchmarking.png|thumb|Screenshot showing a Canvas GUI dialog with 3000 random OpenVG paths (line segments) drawn (for benchmarking purposes) <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=30864&hilit=removeAllChildren</ref>]]
 
 
Continue reading at [[Howto:Canvas Path Benchmarking]] ...


=== Live-Streaming a Canvas via HTTP ===
=== Live-Streaming a Canvas via HTTP ===