Board index FlightGear Development Canvas

Performance issues

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Performance issues

Postby TheTom » Fri Sep 21, 2012 11:47 am

Hooray wrote in Fri Sep 21, 2012 11:27 am:i.e. 80% is spent in Shiva alone.

That's the way it should be as if not changing anything there should only performed rendering which is done by Shiva.

Hooray wrote in Fri Sep 21, 2012 11:27 am:But even without looking at the ShivaVG implementation, this is something where "lazy" rendering would obviously improve things significantly because the texture would only need to be redrawn once it gets updated.

I'm currently working on this one. I have some working code, but it's very hackish. So if anyone has experiences in render-to-texture on demand in OSG any hint is appreciated :)

Hooray wrote in Fri Sep 21, 2012 11:27 am:So reducing the amount of nodes that we write to the property tree,

I'm also thinking about supporting SVG path syntax where the whole path is specified using one string instead of a property for each command/coordinate.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: Performance issues

Postby Hooray » Fri Sep 21, 2012 12:27 pm

If groups could be updated on demand and rendered to a temporary/intermediate texture, before getting merged with the textures from the other groups, that should definitely help us speed up things significantly. Maybe we could even support some form of "meta" information to mark groups as "static" or "dynamic" - so that the canvas knows if children are likely to change frequently (i.e. other traffic) or remain fairly static (such as static things like fixes, navaids, airports).

Obviously, we would need to come up with a clever scheme to handle labeling such that labels may refer to both, static and dynamic features.
Obviously, labels themselves would then need to be put int their own canvas group, which would be marked as "dynamic" - so that they can be dynamically repositioned (using PAL or some other algorithm).

In addition, it might be worth looking into redrawing the texture not only based on listener notifications, but possibly based on a configurable frequency instead - i.e. in many cases, it should suffice to update a texture at 2-5 hz, and not at frame rate. We could support two updating modes: "realtime" (based on listeners) - and timer-based.

In turn, that would also make it possible to use "idle" time for other tasks when the Canvas update() method is invoked, i.e. housekeeping stuff that shouldn't be done when textures are updated.

Supporting a native "path" syntax that would result in less properties being written to the tree, sounds definitely like a good idea to address the sheer amount of data that we are currently writing. This would be particularly useful for complex vector data with a huge number of vertices, i.e. taxiways and other scenery info - which should also come in handy for future shapefile support.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Performance issues

Postby Hooray » Sun Sep 23, 2012 1:44 am

Here's an updated profile using the latest code in git, showing how the total (i.e. 100%) runtime load created by the canvas is distributed JUST within the Canvas subsystem when rendering the airport selection dialog for 2 hrs (note that none of the layers were modified or zoomed during that time):

Image

In Shiva, things look fairly balanced now:
Image

I added a short "stress test" to test the effect zooming has and to look at what canvas functions get triggered, changing the range at 2hz - between 1-10 nm (again, looking at JUST the Canvas system):

26.7% canvas::GeoNodePair::isComplete
16.1% canvas::Map::update
15.8% canvas::Element::valueChanged
9.2% canvas::Group::update
4.6% Canvas::valueChanged
3.3% canvas::SansonFlamsteedProjection::getEarthRadius
3.2% canvas::Map::parseGeoCoord


During the zooming-stress test, the 3 most prominent shiva functions were:

50.3% shPathArrayFind
22.9% shPaintArrayFind
4.5% shProcessPathData


During dialog instantiation, it's still all the listener-"fireworks" that's causing a fair amount of load in the canvas system:

66.7% canvas::Element::valueChanged
33.3% canvas::Map::valueChanged


In other words, it might be a worthwhile test to provide a toggle property, so that listener-notifications can be explicitly disabled, all data written to the tree (without interruptions), and then explicitly trigger the processing, only once.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Performance issues

Postby Hooray » Sat Oct 13, 2012 11:33 pm

Tom has pushed a huge optimization to SG+FG, so that rendering KNUQ (with taxiways) takes less than 4 seconds now. Here are some updated profiling results:

Image
Code: Select all
Total: 376 samples
     218  58.0%  58.0%      218  58.0% int find_child
      18   4.8%  62.8%       18   4.8% _IO_str_pbackfail
      16   4.3%  67.0%       16   4.3% run
      12   3.2%  70.2%       12   3.2% findcell
       9   2.4%  72.6%        9   2.4% free

Regarding the intepretation of these columns, see: http://google-perftools.googlecode.com/ ... ofile.html
  • Number of profiling samples in this function
  • Percentage of profiling samples in this function
  • Percentage of profiling samples in the functions printed so far
  • Number of profiling samples in this function and its callees
  • Percentage of profiling samples in this function and its callees
  • Function name

To enable the collection of these profiling results, build with the previously posted "Google PerfTools" patch applied, and simply set the "DEBUG" variable at the top of "map.nas" to 1, look up "KNUQ" via the airport selection dialog and then enable the taxiways layer.

The chain of events is this:
Code: Select all
#0  0x08b3dd73 in int find_child<char const*>(char const*, char const*, int, std::vector<SGSharedPtr<SGPropertyNode>, std::allocator<SGSharedPtr<SGPropertyNode> > > const&) ()
#1  0x08b445c6 in SGPropertyNode::addChild(char const*, int, bool) ()
#2  0x08819134 in f_addChild (c=0xc4200b0, me=..., argc=2, args=0xc420d14)
    at /home/hooray/BUILD/flightgear/src/Scripting/nasal-props.cxx:365
#3  0x08b289c8 in setupFuncall ()
#4  0x08b2a35a in run ()
#5  0x08b2bd56 in naCall ()
#6  0x0880da93 in FGNasalSys::callMethod (this=0xc326db8, code=..., self=..., argc=4, args=0xbfffe320, locals=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:137
#7  0x0880da0a in FGNasalSys::call (this=0xc326db8, code=..., argc=4, args=0xbfffe320, locals=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:122
#8  0x0881235a in FGNasalListener::call (this=0xced7a08, which=0xccb8ca0, mode=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:1036
#9  0x08812425 in FGNasalListener::valueChanged (this=0xced7a08, node=0xccb8ca0)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:1044
#10 0x08b3e57a in SGPropertyNode::fireValueChanged(SGPropertyNode*) ()
#11 0x08b44f5f in SGPropertyNode::set_double(double) ()
#12 0x085fde13 in copy_from_pui (object=0xcb98d60, node=0xccb8ca0) at /home/hooray/BUILD/flightgear/src/GUI/FGPUIDialog.cxx:502
#13 0x085fe7aa in FGPUIDialog::applyValues (this=0x90dcb78, objectName=0xc46ac70 "display-taxiways")
    at /home/hooray/BUILD/flightgear/src/GUI/FGPUIDialog.cxx:618
#14 0x084b0ae9 in do_dialog_apply (arg=0xcaf25c8) at /home/hooray/BUILD/flightgear/src/Main/fg_commands.cxx:1035
#15 0x08b50ec6 in SGBinding::fire() const ()
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Performance issues

Postby Hooray » Sun Oct 14, 2012 4:43 pm

After Tom's latest changes, there's now hardly any optimization potential left, all the low-hanging fruits are totally gone now:

KNUQ taxiways:
Code: Select all
Total: 143 samples
      26  18.2%  18.2%       26  18.2% _IO_str_pbackfail
      14   9.8%  28.0%       14   9.8% run
       9   6.3%  34.3%        9   6.3% malloc
       8   5.6%  39.9%        8   5.6% __pthread_mutex_lock
       8   5.6%  45.5%        8   5.6% findcell
       5   3.5%  49.0%        5   3.5% naiHash_sym
       4   2.8%  51.7%        4   2.8% __strtof_l
       4   2.8%  54.5%        4   2.8% free
       4   2.8%  57.3%        4   2.8% reap
       3   2.1%  59.4%        3   2.1% bcmp
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests