Re: [Flightgear-devel] Designs for the subsystem manager/factory.

[Edward d'A. <tru...@gm...>]

On 12 April 2018 at 21:03, James Turner <ja...@fl...> wrote:
> On 12 Apr 2018, at 20:32, Edward d'Auvergne <tru...@gm...> wrote:
>> Relying on string catting, we could easily do both.  I wonder if the
>> concatenating system could be shifted to the base SGSubsystem class so
>> that we make it much easier for any subsystem to have multiple
>> instances running.  This may not have any benefit for fgfs, but I
>> could imagine that others might be excited by the idea.  Well, I
>> noticed that it was implemented independently in a number of
>> subsystems (or subsystem groups such as the instrumentation), so it
>> would standardise it as part of the subsystem internal API.
>
> Okay so my proposal is this: I’ll make the factory changes, also to allow
> using a name suffix for instancing; I agree it’s best done in the base
> class. (I’ll aim to do this in the next week)

This sounds good.  I have WIP local branches constantly undergoing
refactoring where I will add all of the new API to every last
subsystem.  So you know what I am doing behind the scenes, these will
consist of ~4 commits, each of which touches all subsystems:

    1)  Whitespace formatting standardisation of the whole subsystem.
I'm not sure if this should be done or not, but subsequent
refactorings for the robustness testing to decrease the dependency
count and avoid segfaults will probably benefit from this anyway.

    2)  Subsystem API declaration standardisation.  This is a mess and
two declarations (FGPanel) doesn't even match the base class (using
"update(const double dt)").  I'll add c++11 "override" specifiers to
make sure the derived class is using the subsystem API correctly, and
remove the inherited "virtual" keyword.  Here I will add
subsystemName() to all subsystems.

    3)  Addition of subsystem dependency tracking data structures and functions.

    4)  Subsystem factor registration.

This will be merged to next once all subsystems are converted and the
changes seem reasonable.  I'd like to for example first see what
happens with subsystemName() and multiple instantiation.


> I am also going to define the ‘SubsystemListener’ API I proposed because it
> will simplify logic in at least one case I have, and I guess some others.

I can imagine that this will be useful for the future for allowing
subsystems to dynamically adapt to the current situation.  Especially
in cases where fgfs is broken up and only subsets of subsystems are
running.  It should also be particularly useful in the test suite.


> Once I’ve done that, and likely after a pause, I want to really think about
> cleaning up the renderer API, so that subsystems (or should-be-subsystems,
> eg SGSky) can more cleanly insert *and remove* their pieces from the scene.
> I have the impression this would really clean up some of the dependencies.
> However, it would be nice to do these changes in discussion with you, since
> I can guess it might overlap with your work for sure.

When fixing the missing precipitation and particle bugs, I noticed OSG
manipulations all over the place with no real organisation.  To me a
lot of it looked far to brittle and not at all designed for the
subsystem concept.  This needs a good clean up and a clean and
thread-safe internal API designed for it!  But it might be so
disruptive that maybe a topic branch might be the best place for the
changes?  For the test suite I will need to modify the behaviour of
FGRenderer as we will need to implement a true "headless" mode.
Querying the scene graph, including performing scene graph dumps,
could be useful for quite a number of tests.  And, probably also of
interest especially for debugging graphics card driver issues,
switching to offline rendering to dump to a bitmap and check
individual pixels (in this case having users download and execute the
run_test_suite binary and any associated data files may be useful).
Anyway, I would assume that there will be overlap.

Regards,

Edward