Callbacks: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (preparations for merging with Timers and Listeners and setting up a redirect there)
Line 2: Line 2:


== Listeners ==
== Listeners ==
'''Listeners''' are a way to register event handlers to be executed once  a property is modified/written to (updated). This is accomplished using the SGProeprtyChangeListener API (link) in SimGear.
Listeners are the most common method for running custom Nasal callbacks (functions), the other being [[Timers]].
many subsystems are modifyinig properties, which may in turn invoke Nasal callbacks (possibly even without being aware of the implications).
the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations
In a sense, timers are "active" - while listeners are "passive", because they get only ever invoked once the property is modified. Still, the reason for using timers is usually saving resources - by running certain code at configurable intervals.
In other words, there are subsystems that run Nasal code, without showing up in the Nasal category - such as property tree or events system.
Still, that doesn't currently tell you which code (function, loop, file, line number etc) is really adding up/expensive.
{{FGCquote
|1= Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) For some of your listeners it may be enough to set the second optional argument to 0, so that the listener code is only triggered when the node value changes. Just turn on listener logging or put a print() message into it to see the costs.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/15645351/
  | title  = <nowiki>Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes</nowiki>
  | author = <nowiki>Melchior FRANZ</nowiki>
  | date  = Oct 24th, 2007
  | added  = Oct 24th, 2007
  | script_version = 0.25
  }}
}}
* [[Using listeners and signals with Nasal]]


== Timers ==
== Timers ==


* [[Nasal Callbacks Explained]]
* [[Nasal Callbacks Explained]]

Revision as of 17:55, 20 February 2016

In FlightGear, a callback is a function that will typically be invoked by either a Timers or a property Listeners

Listeners

Listeners are a way to register event handlers to be executed once a property is modified/written to (updated). This is accomplished using the SGProeprtyChangeListener API (link) in SimGear. Listeners are the most common method for running custom Nasal callbacks (functions), the other being Timers.

many subsystems are modifyinig properties, which may in turn invoke Nasal callbacks (possibly even without being aware of the implications).

the settimer() and setlistener() APIs are particularly tedious to manage properly - but the de facto practice is to use those as the main building blocks to write/integrate full subsystems into the FlightGear main loop - tiny coding errors may not have much of an effect, but under certain circumstances, those coding errors will add up (i.e. over time), so that the original "task" of checking your inbox once per hour, ends up being executed hundreds of times per second - the underlying code would still be correct though, it's just the event handling code that is not written correctly, which is often the case when using reset/re-init or when changing locations

In a sense, timers are "active" - while listeners are "passive", because they get only ever invoked once the property is modified. Still, the reason for using timers is usually saving resources - by running certain code at configurable intervals.

In other words, there are subsystems that run Nasal code, without showing up in the Nasal category - such as property tree or events system. Still, that doesn't currently tell you which code (function, loop, file, line number etc) is really adding up/expensive.

Cquote1.png Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) For some of your listeners it may be enough to set the second optional argument to 0, so that the listener code is only triggered when the node value changes. Just turn on listener logging or put a print() message into it to see the costs.
— Melchior FRANZ (Oct 24th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes.
(powered by Instant-Cquotes)
Cquote2.png

Timers