On Saturday 04 April 2009, Melchior FRANZ wrote:
> * Heiko Schulz -- Saturday 04 April 2009:
> > How would it be better, and would all what Tim wants to do,
> > be still possible?
>
> The features that Tim is talking about (effects and stuff), and
> the XML and property tree representation do IMHO not have much
> to do with each other.
>
>
> How can separate values be stored without vector property type:
> Just like now. Every "property" (red/green/...) is a an actual
> *property* (i.e. an SGPropertyNode). But we had that aleady ...
>
>
> What the best solution for the "dynamic" attribute is probably
> depends on the case. How often do we expect such color properties
> to change? Many of them in every frame? Or just a few every few
> minutes?
>
> One solution could be to have the properties just like now
> (with children possibly tied to memory):
>
> color/{red,green,blue,alpha}
>
> Add a listener to the parent "color", and trigger it when all
> color properties have been set, so that the code can update
> whatever needs to be updated. The triggering happens with
> SGPropertyNode::fireValueChanged(). This can be nicely done
> with a few helper functions. Of course, triggering the parent
> would have to be done manually in the property browser or via
> telnet, but that's certainly not the main use case and is IMHO
> acceptable.
>
> No intrusive changes with multiple bad side effects needed.
>
> m.
I too think the that the real issue here is the representation in
the property tree, not functionality. As long as the data is
available in the property tree it shouldn't affect the
functionality at all because it'll be trivial to convert from the
current property tree representation of the data to the form
required by OSG.
I still can't see a good reason to make changes to the way the
property tree represents data unless the overhead of accessing
three or four property tree nodes, instead of just one, has a
significant impact on performance.
How frequently does this data need to be accessed?
LeeE
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
