On Wednesday 08 April 2009, Tim Moore wrote: > LeeE wrote: > > I've been following this but I don't remember anyone, in either > > camp, pointing out where it brings a significant performance > > increase, or where the failure to adopt it will result in a > > significant performance drop. I specifically asked about this > > in one of my earlier posts but if anyone answered I must have > > missed their replies. > > Here's the theory: the values in question, such as material > colors or vector parameters for a shader, must be set in a vector > operation in OSG. The values are set at startup and also at > runtime by material animations. Typically the raw C++ values that > could be set by a property system "tie" are protected members and > not accessible. > > Currently a big performance hit is the need to run an update > callback on every state set involved in a material animation (not > to mention on every animation). It might not seem like this could > be expensive, but the need to traverse the big scene graph every > frame is expensive in terms of what is costly on today's > hardware: pointer chasing, cache misses, etc. If we can move away > from update callbacks, we will see a gain.
Ok - seems fair enough. > However, if the individual components of the values in question > exist independently in the property tree and can be set > individually, this greatly complicates the bookkeeping needed to > avoid update callbacks, or forces us to just use update callbacks. It seems to me then, that if the data is updated in the tree, update callbacks will be required. If just a single property node is updated then just a single update callback will be required but if three nodes are needed to be read, when perhaps only one has been updated, then three update callbacks will be needed. However, even though using a single node results in just a single update callback instead of three, whatever is updating that data will still need to work with the individual values and so will not only need to parse the node to extract the three values before it works with them, but also re-form the compound data item when it wants to write it back to the node. It seems then, that there will be an overhead whichever way we look at it; if the overhead is removed from the OSG point of view, it's just added to whatever other subsystem is updating the data. How often is this data likely to be updated, and does this data really need to be exposed in the property tree anyway? > > > As for the idea that the new datatypes should be adopted on the > > principle that if they do turn out to cause problems they can > > be fixed later, well, no offence intended Durk, but that just > > seems extremely foolhardy to me. Planned development? - we've > > heard of it. > > "Agile development" is the new hotness :) > > Tim To me, "Agile development" just seems to be the latest developer-centric buzzword for an approach to software development that puts the importance of the introduction of new features over maintaining software quality, and to be honest, I think FG has enough problems with quality as it is. To be fair, in many respects FG is still seeking solutions to problems i.e. get it working before worrying about making it perfect. The thing is though, are the solutions actually being refined and de-bugged adequately once they've been got working? I would have to say not, because I've been watching the cvs updates come through, specifically looking for fixes to a number of problems that have been reported, but which show no signs of being dealt with. To coin an old Windows joke, rather than FG just working, FG works, just, and agile development is going to do nothing to improve this state of affairs. LeeE ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
