Hi Hyde,
sorry for the confusion.
Yes, what Thorsten and sa7k said is correct: Stuart has extended the airport selection dialog to also show a map of the selected airport, using the new 2D drawing system in FG, called the "Canvas".
Under certain circumstances this was causing severe lag/performance issues - especially when viewing airports with complex taxiway networks, which involves the creation of ~1200 OpenVG paths in the property tree - so most "slowness" was in fact caused by overly excessive use of the property tree.
Tom has recently optimized this quite significantly. So that even complex airports like KNUQ are now reasonably fast.
So first of all, I'd make sure that you are using the latest code from SG/FG/FGDATA.
That said, it would help if you could be a little more specific here - according to your initial description, it sounds like the dialog itself, i.e. loading it, is extremely slow for you, even without doing any actual airport lookups, i.e. even when not using the canvas at all?
I've seen that a couple of times here on an old computer of mine, but otherwise it's fairly fast.
However, I do believe that it would be possible to optimize even the initial loading further.
Some people have noticed similar issues when using the canvas for the first time, i.e. due to initialization overhead.
Arguably, related to some hardware specifics, like OpenGL support (?)
Could you please check if that's the case here? In other words, if it's related to the initialization of the canvas system, closing and re-opening the dialog should perform much faster, because the system would have been initialized already.
However, note that this may not even be related to the use of the canvas system: Stuart's new airport selection dialog also uses a bunch of Nasal APIs to do airport lookup. Which in fact, seems fairly slow here, too. I think it's related to the fact that the API is not designed in a lazy fashion, so that it will always get all the info.
Overall, I am sure that we can get the issue sorted if you could provide a little more feedback - ideally, using the canvas forum:
http://www.flightgear.org/forums/viewforum.php?f=71Finally, please don't get Thorsten's remarks wrong: Most of us are aware of the fact that you are one of the most active aircraft developers here, and that the 777 has become one of the most-completely (and most actively) developed aircraft, and we are really grateful for your work!
However, with your backgound, you'll surely understand that we can only properly troubleshoot such issues if people speak about them and actually provide useful feedback in response to the questions we raise (see above).
Now, with your aircraft developer background and coding abilities (including your ability use git and build from source obviously), you'll probably want to take another look at the thread that sa7k linked to: it contains a patch that I posted, which adds two new fgcommands:
profiler-start and
profiler-stop - these can be used to get extremely fine-grained performance information on specific parts of FG. You can easily bind them to keyboard hotkeys, or simply use Nasal's
fgcommand() to call them during instantiation of the dialog.
That should tell us exactly what's taking so long there, so that we can further optimize things.
Note, that you'll need to install Google PerfTools first:
https://code.google.com/p/gperftools/?redir=1And then apply the patch here:
http://www.flightgear.org/forums/viewto ... 50#p166967Next, open $FG_ROOT/gui/dialogs/airports.xml and add
fgcommand("profiler-start"); to the beginning of the Nasal
<open> block:
https://gitorious.org/fg/fgdata/blobs/m ... xml#line39Next, add
fgcommand("profiler-stop"); to the end of the same block, or if that's not conclusive, to the beginning of the canvas' Nasal (load) section in $FG_ROOT/Nasal/canvas/generic-canvas-map.xml, i.e. around here:
https://gitorious.org/fg/fgdata/blobs/m ... xml#line84You may also want to use Nasal's systime() command to see how long the instantiation actually takes.
Afterwards, you can safely close FG (or run fgcommand("exit")) and inspect the file fgfs.profile created in the CWD from where you started the whole thing.
To actually process the file, use
pprof: pprof --text /path/to/fgfs /path/to/fgfs.profile > profiling.results
When doing this here on a really old computer from 2006, I'm getting the following results, which illustrate that James' new SQLite-based NavDB cache is the main culprit here, not the Canvas:
- Code: Select all
47 29.6% 29.6% 47 29.6% sqlite3VdbeExec
22 13.8% 43.4% 22 13.8% __read_nocancel
8 5.0% 48.4% 8 5.0% lseek64
7 4.4% 52.8% 7 4.4% sqlite3VdbeMemRelease
4 2.5% 55.3% 4 2.5% likeFunc
4 2.5% 57.9% 4 2.5% sqlite3DbFree
4 2.5% 60.4% 4 2.5% sqlite3VdbeMemMove
3 1.9% 62.3% 3 1.9% _IO_str_pbackfail
3 1.9% 64.2% 3 1.9% fetchPayload
3 1.9% 66.0% 3 1.9% sqlite3BtreeCursorHasMoved
3 1.9% 67.9% 3 1.9% sqlite3VdbeMemGrow
3 1.9% 69.8% 3 1.9% sqlite3VdbeRealValue
2 1.3% 71.1% 2 1.3% 0063154b
2 1.3% 72.3% 2 1.3% btreeParseCellPtr
2 1.3% 73.6% 2 1.3% memcpy
2 1.3% 74.8% 2 1.3% pcache1Fetch
2 1.3% 76.1% 2 1.3% sqlite3BtreeDataFetch
2 1.3% 77.4% 2 1.3% sqlite3BtreeDataSize
2 1.3% 78.6% 2 1.3% sqlite3ValueText
2 1.3% 79.9% 2 1.3% sqlite3VdbeMemNulTerminate
2 1.3% 81.1% 2 1.3% sqlite3VdbeSerialTypeLen
2 1.3% 82.4% 2 1.3% sqlite3_mutex_leave
2 1.3% 83.6% 2 1.3% sqlite3_value_text
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
Note that this seems like a known issue according to:
https://code.google.com/p/flightgear-bu ... ?id=894#c5I'd suggest to also post your info there.
Please share your results with us.
When you do post your findings here, please also post your system/hardware specs and any console warnings or errors you may see while using the airports.xml dialog.
HTH
Thanks