20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→supporting master/slave setups
| Line 48: | Line 48: | ||
* '''Omega95''': "Supporting 3D objects to be projected onto canvas" [http://flightgear.org/forums/viewtopic.php?f=71&t=17278#p164260] | * '''Omega95''': "Supporting 3D objects to be projected onto canvas" [http://flightgear.org/forums/viewtopic.php?f=71&t=17278#p164260] | ||
=== Supporting distributed master/slave setups === | |||
I'd just thought I'd share this, so that we are aware of some shortcomings, and ideas on addressing them: | |||
There's a handful of threads where we talked about configuring multi-instance setups. This | |||
We have a bunch of options for configuring multiple fgfs instances in a master/slave fashion, where an arbitrary number of slaves can be driven through a single master instance, important properties are sync'ed/replicated through a socket connection. Specific subsystems often have custom hard-coded protocols, for syncing certain state (joystick, fdm, controls etc) | |||
This is an old feature, which is still working - but many more recent features do not properly/fully support it. The canvas being one of them. | |||
However, it still is an important feature, that is also used at various event to demonstrate FlightGear to new users, such as e.g. FSWeekend and LinuxTag. | |||
The underlying issue is pretty common in FG, can be seen in many places - such as clouds/weather not being in sync, AI traffic, animations/effects etc | |||
Often, this requires lots of work to fix properly, because subsystems were not really designed to serialize internal state via the property tree, so there's lots of "private" state that never shows up in the tree, and there are no hooks to send events to sync things. | |||
However, the Canvas is a different "beast", because it is already built on top of the property tree, much moreso than any other subsystem probably. | |||
A while ago, we talked about the idea of supporting something like FGCanvas, analogous to FGPanel - which is also just about synchronizing properties in a master/slave fashion once you think about it. | |||
Back then, we briefly talked about the idea of "mounting" a property tree in a remote instance to sync state properly and to formalize master/slave relationships. | |||
I have been able to get this somewhat working by using the telnet protocol, and its "subscribe" command to get updates for the /canvas branch in the main instance - the power of canvas & the property tree makes that pretty simple. However, it's really crude, because it will get all update notifications, without being selective - because instances don't know anything about the master, and about stuff that would be redundant to do. | |||
So, that's a use-case for which the canvas wasn't really designed obviously: basically, you end up with two canvas subsystems, without the 2nd/slaved system being aware that it is a slave, and that it should not do certain things, and instead rely on CERTAIN data from the master. Instead, the 2nd canvas system may override some received state, with its own internal state currently. In other words, I may be having multiple canvas instances in each fgfs instance, that is not aware of what the other one is doing, as long as it's a really simple instrument/dialog, it doesn't matter - but things fall quickly apart once things become more sophisticated. | |||
To address this, I am thinking in terms of adding a property attribute to mark certain properties as master/slave, so that a sync/replication mechanism at the property tree level knows exactly which properties to send/request, and which ones to compute locally. | |||
Also, I would want to formalize properties as being "input" or "output" properties, so that the canvas system knows for example that a certain property is a "readonly slave" property, i.e. comes from the master and cannot be affected locally. | |||
Even if we should not use a manual sync method, the HLA work will also benefit from subsystems having a concept of properties being "master" or "slave". Torsten's fgpanel work is another obvious example that would benefit from knowing more about properties being master or slave - equally, the multiplayer and replay/flight recorder subsystems could benefit from such info. | |||
IIRC you are using PropertyObjects<> - so my current idea would be to extend that class and allow such attributes to be specified via enums, i.e. to mark properties as master/slave and input/output, so that certain code paths can be made optional, because they should only be done on the master or slave side. | |||
The sync mechanism/protocol could then traverse the canvas tree and check which properties it needs to subscribe to from the master, and which ones are client-side | |||
Given that more and more systems are going to switch over to the canvas (HUD, instruments, MFDs), it would make sense to come up with a mechanism that allows multi-instance setups to be properly sync'ed - especially because this is something that all the hard-coded MFDs are also not very good at (NavDisplay, wxradar etc) | |||
In other words, the question would be how to better support use-cases where an aircraft that relies on canvas-MFDs, like zhr C130J for example, is simulated by multiple inter-connected fgfs instances - another valid scenario would be our existing "dual-pilot support", which goes to show that we should keep in mind such synchronized master/slave setups. | |||
Thoughts / better ideas ? | |||
=== Adressing modes: by-index, by-name (property mounting) === | === Adressing modes: by-index, by-name (property mounting) === | ||