On Thu, 2003-02-06 at 01:09, James Turner wrote: > On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: > > > <excerpt><excerpt>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? > > </excerpt> > > This is a good discussion to start. I'm inclined to eliminate tying > > altogether and have every module set properties explicitly; what does > > everyone else think? > > </excerpt> > > Couldn't agree more, but I think this is likely to be unpopular. We > can keep tying if we have an efficient 'notifyTiedValueChanged' > method, which should be a no-op if there are no change-listeners > registered on the property, and otherwise should run through them. > > > Tony Peden wrote, > > > <excerpt>I'd really like to see tying stay in. I'm not sure we ever > would have > > incorporated the property tree into JSBSim without >it.<color><param>0000,6363,1212</param> > > </color></excerpt> > > I don't understand why
The memory vs. cpu cycles trade is appealing to me. For the cost of storing the function pointers needed to make tying work, we get a system that only consumes CPU cycles when a property is actually accessed. The only alternative I see for us(and please tell me if there's something I'm missing) is an explicit copy every frame. In the case of the FG property browser, you may be able to limit the explicit copying to when the property browser is shown, but there is no such opportunity with JSBSim. > > > xPosNode.setFloatValue( xxxxx ) > > > is so much worse than > > > my_tied_xPos_float = yyyy > > > apart from being a bit verbose. And the advantage is, it forces you to > appreciate (when you do the set) that some extra working is going to > get done (listeners being invoked for now, who knows what else in the > future) > > > > Jim Wilson wrote, > > > <excerpt>Ummm...it's not polling, it's just updating the data. Same > as many of the > > subsystems do every frame. Polling is a contious loop that waits for > > something to happen. Like I said, if we're not displaying the > prop_picker > > then it should > > not be updated.<color><param>0000,6363,1212</param> > > </color></excerpt> > > Well, I take polling to mean, going and looking at a value over and > over again (one 'look' per frame). That works fine, and I'm *not* > trying to argue an efficiency point (sorry if my original email came > across that way, since that's how most people seem to have taken it). > It's an issue of dataflow in the program : should it be driven by the > people updating the values, or by people reading them? > > > Basically, I can envisage lots of things the ChangeListener API is > perfect for, whether you're observing a value that changes one a week > or 50 times a second, but right now those things won't work because > some % of the properties don't tell you they've changed. Now, we could > always flag some properties as 'immediate' I suppose, but that seems > like a hack. There's nothing wrong with the current API, we just ought > to make all the property nodes meet the contract it defines, or we > need to remove change listeners from the API and have everyone poll / > update as you suggest. > > > H&H > > James > > -- > > That which does not kill me has poor aim -- Tony Peden <[EMAIL PROTECTED]> _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
