Simulated-dt timers

[zakalawe]

(Cross-posting from the mailing list, reply there if possible but probably good to have this widely known!)

I noticed that our current Nasal timers don’t expose the ‘sim vs realtime’ option from the Event-manager, so I’ve pushed a change to fix this. It’s via a boolean attribute ‘simulatedTime’, defaults to false for backwards compatibility. The ‘settimer’ approach does support this flag since ‘forever’ but of course settimer should eventually be replaced with timer-objects to reduce GC thrash in Nasal.

The attribute can’t be changed while the timer is running, BTW. But you can stop the timer, change the value and start it again.

I would guess > 50% of Nasal timers should be using simulated time, so pause and sim-speed-up work automatically, but I didn’t have the nerve to change the default. If people want to convince me otherwise, we can try it

[Hooray]

We previously talked about that on the forum, it should be "relatively safe" to get rid of (rename) _settimer() and use a Nasal-space wrapper that merely ends up calling maketimer(), which retains the object and binds a listener to /sim/signals to handle with pause/re-init/reset etc - at that point, settimer() could be phased out over time.

However, from a troubleshooting/debugging standpoint it would still make sense to use a separate SGEventMgr instance and register that using a corresponding alias like "nasal-timers" to make things more obvious (performance monitor, or a dedicated UI for listeners/timers), for the corresponding C++ patches, refer to:

Subject: Nasal Callback tracking (timers & listeners)

http://sourceforge.net/p/flightgear/mailman/message/34810857/

it's relatively easy to do bad things
unintentionally. Like tie a bit of code to an FDM property and run updates
of a display 120 times per second rather than the 30 times you actually
need. Like start a loop multiple times so that you update the same
property 30 times per frame rather than the one time you actually need.

It's actually pretty hard to catch these things, because the code is
formally okay, does the right thing and just eats more performance than
necessary, and there's no simple output telling you that you're running 30
loops rather than the one you expect. The only way I've found is to clock
down loops and print to console inside them - when you clock them per
second and see 30 messages printed each second, you know that something is
afoot...

So it's really not impossible to come up with aircraft Nasal that ends up
using a hundred times more performance than it has to. Unfortunately,
better CPU utilization is not really the way to attack these problems
though....

given that this obviously a recurring problem, I was wondering what we could do abot this - so I started prototyping a Nasal/Canvas-based UI to for displaying active Nasal callbacks (i.e. timers & listeners).

And I think it would be a good idea to gather some feedback to determine what kind of data would be useful and how it should be ideally represented - obviously, the screenshot below is not much more than a mockup (well, it is working Nasal code, just the data that is shown is arbitrary) - but otherwise, exposing the SGEventMgr logic at the Nasal level to provide a list of active events, including their callbacks (and location in Nasal code, i.e. filename and line number) is relatively straightforward.

So what else do we need to come up with an intuitive "task monitor" that shows Nasal callbacks registered in the form of timers and callbacks ?

Should we differentiate between aircraft and scenery code, between different sub-modules ? Technically, that would be possible to do, because we will need to patch some C++ code anyway - i.e. roughly 50-100 lines of code in both SG and FG will need to be touched to expose the SGEventMgr queues to scripting space (or even just in the form of live properties that are updated each frame)


http://wiki.flightgear.org/Howto:Troubl ... _Callbacks