James Turner writes: > I'm pretty adamant that's the wrong way to do this, we're reduced to > polling. Being anal for a second, SGPropertyNode is an interface, and > therefore is supposed to make some guarantees about it's behavior. One > of these is that changeListeners are correctly invoked. Sure the > property picker dialog can do polling, but that's wasteful for > infrequently changing values. If there's a performance issues with the > core values needing to notify listeners, that's something we need to > address too. > > BTW, I assumed listeners worked, because I figured several things, such > as updating panel state, the telnet property browser and so on used the > changeListeners: are they actually all using polling?! > > If so, seems like we're kind of shooting ourselves in the foot .... or > am I just being super-anal and should just poll them as Jim Wilson > suggests?
First of all, it might make sense in this case to actually try updating the data every frame to see exactly what kind of performance implications there might be. We have to redraw all the pixels of each value using opengl calls and textures for every frame, so what is the relative cost of updating the contents of a couple char arrays? Even if the net performance is slightly slower, my guess it that it won't be measurable. In that case it's proably not a bad thing to do. Looking at it another way, if the user has the property browser open, they are probably more concerned with debugging and could put up with a very tiny frame rate drop (while the debugging window is open.) There is already going to be some performance cost because we are drawing extra stuff. In my mind, as long as it isn't a huge hit (which I can't imagine it being) then it's probably worth doing. As David points out, the property manager has no way to detect a change in an external value it is tied to ... short of storing the last value of each element in the property tree and comparing to the current value each frame, but that would certainly impose an even greater performance hit that just redrawing a couple values we are interested every frame. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
