Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Howto:Exposing Subsystems to Nasal

From FlightGear wiki
Revision as of 07:46, 7 February 2016 by Hooray (Talk | contribs) (Roadmap)

Jump to: navigation, search
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.


Objective

Document how existing FlightGear subsystems (i.e. those inheriting from SGSubsystem) can be exposed to Nasal space to make certain information available to Nasal space.

Focus

This article will specifically cover how to access the FlightGear event manager (SGEventMgr) and the listener API (SGPropertyChangeListener) to track registration and invocation of Nasal callbacks per frame.

Background

The main mechanism for triggering scripted Nasal code to be executed within the FlightGear main loop are so called listeners (Nasal callbacks that are stored in a property-specific vector/list, that get executed in a for-each loop whenever a property is modified), and timers, which represent "delays" (typically in seconds or milliseconds) after which a timer expires and fires its callback to be executed.

Unfortunately, these two mechanisms are rather low-level and tedious/error-prone to use correctly, so that code (Nasal callbacks) may be triggered accidently, and unnecessarily, which ultimately eats up considerable resources while creating a frame, sooner or later causing frame stuttering.

Even more unfortunate is the fact that FlightGear does not currently provide any mechanisms/APIs to look behind the scenes, i.e. to see how often a callback is actually executed, and where the callback is registered to be executed.

This article intends to document the steps required to expose meta information about timers and listeners to scripting space so that a Nasal/Canvas bsed UI (dialog) can be displayed with a list of active callbacks, and their runtime characteristics.

However, the underlying timer/listener APIs are not specific to Nasal scripting but also commonly used elsewhere (in fact, in most other subsystems), and they are also infamous for buggy C++ code that similarly affected FlightGear performance.

This will include patches to all 3 repositories of FlightGear, i.e. SimGear, FlightGear and fgdata.

Approach

We will be providing additional methods to obtain access to otherwise private fields/data (members) and make those available to FGNasalSys.

Roadmap

  • extend the destructors of the timer/listener objects to dump destruction info to the log via SG_LOG Not done Not done
  • extend SGTimerQueue to provide methods for getting the size of the queue Not done Not done
  • extend SGEventMgr to dump that info to the console via the SG_LOG macro Not done Not done
  • add a counter to keep track of timers registered via settimer/maketimer Not done Not done
  • add a counter to keep track of listeners registered via setlistener Not done Not done
  • add a per-frame resetting counter to keep track of callback invocations per frame Not done Not done

Status

Patching

SimGear

FlightGear

Base Package