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. 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. > 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 ------------------------------------------------------------------------------ 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
