Board index FlightGear Development Canvas

Select Airport menu has long delay to display

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.

Select Airport menu has long delay to display

Postby Hyde » Wed Oct 17, 2012 2:22 pm

I'm using git version of FGFS and Select Airport menu has been changed recently. After that Select Airport menu has a long delay to display initial screen.
I prefer display something when press menu or previous menu.
Last edited by Hyde on Mon Nov 12, 2012 8:23 pm, edited 1 time in total.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Select Airport menu has long delay to display

Postby Thorsten » Wed Oct 17, 2012 4:20 pm

As far as I know, it's being moved to a different technology (canvas) - if you use GIT, you implicitly agreed to live with any such inconvenience characteristic for a development version.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Select Airport menu has long delay to display

Postby Hyde » Wed Oct 17, 2012 4:37 pm

Do you mean it will be improved in the future if we are complaining?
I just wanted to know that the developer recognized this as an issue.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Select Airport menu has long delay to display

Postby sa7k » Wed Oct 17, 2012 5:28 pm

You should update if you didn't lately, it has been improved a lot with this weekend changes. Hooray made a post about that.
http://www.flightgear.org/forums/viewtopic.php?f=71&t=17650&start=15#p168565
sa7k
 
Posts: 380
Joined: Fri Mar 16, 2012 3:24 pm
Location: SA7K
Callsign: LV-EPM
IRC name: sa7k
Version: git
OS: debian

Re: Select Airport menu has long delay to display

Postby Thorsten » Wed Oct 17, 2012 7:37 pm

I just wanted to know that the developer recognized this as an issue.


No, as a rule developers are dumb and do not care for things like loading time or performance and wouldn't possibly notice such issues unless you mention them and complain frequently *irony*.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Select Airport menu has long delay to display

Postby Hooray » Fri Oct 19, 2012 1:06 pm

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=71

Finally, 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=1
And then apply the patch here: http://www.flightgear.org/forums/viewto ... 50#p166967
Next, 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#line39

Next, 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#line84

You 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#c5
I'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
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Select Airport menu has long delay to display

Postby Hyde » Sat Oct 20, 2012 11:28 am

Hooray, thanks for your warmful reply.

I thought this issue happened on all of us but I was wrong.
I ran FG on another two machines which had even low performance but this did not happen. Now I understand why I haven't gotten any response.

I didn't mention how long the delay was, my bad.

Here's the phenomenon.

Only first time after machine boot to open Select Airport menu, FG response stop about 30seconds without any indication even the busy mouse cursor. During this period, disc access continues.
After this, menu opens without delay until next machine boot.
That means not the issue of canvas, right?

I couldn't have time to run trouble shooting yet. I'll let you know once done.

Thanks again,
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Select Airport menu has long delay to display

Postby Thorsten » Sat Oct 20, 2012 4:43 pm

Finally, 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!


I would like to make it very clear that I find the style of the first post not acceptable as a feedback. Any merits of the 777 have nothing to do with that, indeed it makes matters even worse in my view because then you should know better.

1) GIT is a development version, i.e. frequently things change or are in transition, do not work or appear strange. It's just a fact of development. If anything minor is broken, 90% of the time it means someone is currently working on it and the problem disappears after a few days, so immediate reports just generate noise but don't help anyone. Monitoring the devel list gives one a good idea what is currently being worked on - it also has alerts when potentially troublesome features as pushed. In the remaining 10% of cases, some change had unexpected repercussions elsewhere which don't show up immediately. In this case, it's a good idea to ask if anyone else has bad experiences rather than complain. Also it's a good idea to specifically ask the person who likely did the change.

2) Any broken feature needs a proper bug report. Saying 'X is slow, I want the old version back' is not a bug report, it's just a complaint which, for the sake of information exchange, is just marginally better than noise.

3) If a problem is seriously annoying and does not get fixed within a week, you can be pretty sure it affects only you or a small number of people. Developers sometimes do use Flightgear themselves and tend to note problems they have caused and then address them. I don't know of anyone who introduced a major bug on GIT and just left it there for a month because he didn't care. To assume that developers would not care if something runs very slow or responds slowly is equivalent to assuming that developers are dumb - they're not. But if it's a problem affecting only you, you need to supply extra information because it's very hard to debug otherwise.

4) I find the whole tone of your first two posts impolite and not constructive.

It's not rocket science to work all these things out. One would think that you should really know better than that, but I am glad that there's constuctive dialog emerging after all.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Select Airport menu has long delay to display

Postby Hooray » Sat Oct 20, 2012 4:59 pm

Thorsten, not disagreeing with your more general point, but Hyde's issue is in fact a little obscure, but has been reported by other users, too - and is obviously related to some of Zakalawe's NavDB cache work, which has been also covered on the devel list: https://code.google.com/p/flightgear-bu ... ?id=894#c5

I am in the situation that it's performing really well on 2 computers here, while it performs really badly on another one - so the bug report is useful, and we should definitely work out a way to identify the issue at hand and address it promptly. This is why I have suggested to move the whole issue over to the issue tracker, and send a heads-up to Zakalawe, the person who is most likely to the right person to address the issue.

Obviously, not everybody here is able to really run development tools like debuggers or profilers, and rebuilding from source (or using git) is another complex issue (as you undoubtedly know). So making good bug reports can be a little bit difficult at times (especially when dealing with obscure issues) and we need to understand that. But having to wait for 30 seconds until a dialog appears is clearly wrong and not intended.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Select Airport menu has long delay to display

Postby Thorsten » Sat Oct 20, 2012 5:08 pm

I do not disagree with reporting issues as such, and there seems to be an issue here. I disagree with the way this was done, and there is room for future improvements here :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Select Airport menu has long delay to display

Postby Hyde » Mon Oct 22, 2012 11:40 am

I'm sorry, Thorsten.
I should not have said that.
Since I'm not a native English speaker sometimes my wording is gruffness. I will be careful.

Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Select Airport menu has long delay to display

Postby Hooray » Mon Nov 12, 2012 6:16 pm

Hyde, there have been made some navDB related commits recently, has the situation improved for you in any way or are you still seeing severe lagging in terms of halting for several seconds? If so, please report back via the issue tracker.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Select Airport menu has long delay to display

Postby zakalawe » Tue Nov 13, 2012 6:39 am

The select-airport and map dialogs can both have some long pauses at the moment - I am working on improving this, or at least giving some better feedback. Here 'long' might mean 5-20 second, or even just 1-2 seconds.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Select Airport menu has long delay to display

Postby Hyde » Tue Nov 13, 2012 2:00 pm

Hooray wrote in Mon Nov 12, 2012 6:16 pm:Hyde, there have been made some navDB related commits recently, has the situation improved for you in any way or are you still seeing severe lagging in terms of halting for several seconds? If so, please report back via the issue tracker.

Thank you, Hooray. Yes, the latest GIT does not have such a long delay (25sec). It's now less than 1sec but durable. :D

zakalawe wrote in Tue Nov 13, 2012 6:39 am:The select-airport and map dialogs can both have some long pauses at the moment - I am working on improving this, or at least giving some better feedback. Here 'long' might mean 5-20 second, or even just 1-2 seconds.

Thanks. Airport dialogue has much improvement now. Map has still. I made another topic.
http://www.flightgear.org/forums/viewtopic.php?f=17&t=17969
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Select Airport menu has long delay to display

Postby Hooray » Tue Nov 13, 2012 4:08 pm

zakalawe wrote in Tue Nov 13, 2012 6:39 am:Here 'long' might mean 5-20 second, or even just 1-2 seconds.


Not seeing anything like this right now on 3 different Linux computers, 32bit and 64bit.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests