Board index FlightGear Development Canvas

Performance: NavDB / Positioned APIs (#1320)

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.

Performance: NavDB / Positioned APIs (#1320)

Postby Hooray » Wed Jun 11, 2014 2:45 pm

http://code.google.com/p/flightgear-bug ... id=1320#c6
Philosopher wrote:flickering and "stick[ing]" are different things -- it will still stick/stutter/stop at high ranges when it has to re-search, which is related to the underlying positioned code (but yes it won't flicker any more -- that's fixed but irrelevant to this issue).


James just discussed plans on the devel list to "address" such navdb performance issues in the aiport-selection dialog by simply not using those positioned APIs when initializing :D

http://sourceforge.net/p/flightgear/mai ... sg32445912
Zakalawe wrote: restructure the ‘airport select’ dialog to remove the scrolling airport list. This would dramatically speed up opening the dialog. Instead we’d have the current airport selected, a text input field with a ‘search’ button and ideally a ‘nearby’ button like we do in the ‘ATC services nearby’ dialog. When search has multiple matches we’d show some list UI in a popup, but it would be capped to some small number such as 50.


All accesses being read-only, I still don't quite see/understand what exactly is preventing us from running the whole navDB shebang in a SGThread with a MUTEX-synchronized queue that serializes all queries (if that turns out to be necessary), so that we could "queue" queries and once they complete, run a corresponding Nasal::Callback to fetch the results.
I've done quite a bit of profiling WRT the navdisplay/mapstructure code and I am seeing property tree access and navdb/positioned calls showing up in quite a few of those profiles.

Some aircraft developers, including the extra/Avidyne Entegra R9 folks, are actually using a brute-force scheme and run very aggressive queries during initialization, which basically replicates a huge part of the surrounding NavDB items in Nasal space, so that they don't have to run as many positioned queries later on. I think we saw a similar approach being used by a team of Russian aircraft developers a while ago.

Either way, Tom mentioned a while ago that he wants to get rid of the original NasalPositioned code sooner or later (obviously not in time for 3.2), and the cppbind-based version should hopefully provide better options for sync'ing positioned API calls at the Nasal bindings level.

I am thinking that it would conceptually be the right thing to do to turn the navdb/positioned stuff into a "client/server" subsystem where the navdb acts as a server that can handle client-requests asynchronously. The funny thing is that SQLite itself is obviously based on the whole "server-less" notion.
From a design standpoint, the NavDB is basically an "environmental" subsystem, i.e. heavily reliant on the underlying terrain/scenery because it provides navaids - thus, in a distributed/MP setup it would actually make sense for multi-instance setups to query the same DB to replicate/sync state.

To be honest, I am not even sure if there's any "legitimate" reasons for still doing C++-level queries, i.e. most stuff could/should probably go through cppbind either way, or should at least use a protocol to be async. The only exception I can see are hard-coded gauges, i.e. all the steam stuff that would need some kind of shim wrapper.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests