Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 02:10 pm, David Megginson wrote: I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. I'm happy to have a go at this, or do you (David) want to take a look? i agree it's far and away the best suggestion I've heard in terms of non-impact on the code, efficiency and so forth. -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner writes: I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. I'm happy to have a go at this, or do you (David) want to take a look? i agree it's far and away the best suggestion I've heard in terms of non-impact on the code, efficiency and so forth. Go for it -- I probably won't be able to get to it right away. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: 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? 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? 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, 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. I don't understand why xPosNode.setFloatValue( x ) is so much worse than my_tied_xPos_float = 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, 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. 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. HH James -- That which does not kill me has poor aim
Re: [Flightgear-devel] Live property picker
James Turner wrote: 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. Aren't the C++ opperators the perfect place to add this kind of action to tied properties? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Erik Hofman wrote :
James Turner wrote:
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.
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template class T
class tied_value
{
public:
tied_value() : node( 0 ) {}
~tied_value() : { untie(); }
tie( SGPropertyNode_ptr n ) { node = n; n-tie( val ); }
untie() { node = 0; n-untie( val ); }
T operator=( const T v ) { val = v; if (node) node-fireChangeListeners(); return
*this; }
operator T() { return val; }
private:
T val;
SGPropertyNode_ptr node;
}
Then replace every tied values with that template :
change :
double xPos;
into :
tied_valuedouble xPos;
You get the picture ?
One can use xPos as usual and when the data is changed, listeners are advertised.
( disclaimer : all the above is written from memory and is presumably
incomplete )
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 10:16 am, Frederic BOUVIER wrote:
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template class T
class tied_value
{
snip quite reasonable template idea
}
Then replace every tied values with that template :
change :
double xPos;
into :
tied_valuedouble xPos;
You get the picture ?
I do, but this is not the problem (as I understand it). The tie-ing
system is 'low-invasion' for existing code / code which may not be part
of FG, and works well with existing state variables. Your template /
operator overloading fix the syntax, but I sort of think that's worse,
because people may not realize what they're doing will be more
expensive than assigning to a double. But the main problem is people
now need to pull in your template and the property node headers into
places they don't want to.
The impression I have is that a bunch of code uses 'tieing' to expose
lots of internal variables directly. I'd prefer an explicit
'publishing' phase, i.e calls to setValue. Of course your template
works fine too, if you're prefer the syntactic sugar.
HH
James
--
That which does not kill me has poor aim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner wrote : The impression I have is that a bunch of code uses 'tieing' to expose lots of internal variables directly. I'd prefer an explicit 'publishing' phase, i.e calls to setValue. Of course your template works fine too, if you're prefer the syntactic sugar. I see your (rather dogmatic) point but I also see here people that are not prepared to follow you. My main point is that if there is an interface, it is supposed to work in all cases and my solution address this point. The SGPropertyNode interface can also be change to forbid tying from outside the template to enforce the rule. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner wrote : I do, but this is not the problem (as I understand it). The tie-ing system is 'low-invasion' for existing code / code which may not be part of FG, and works well with existing state variables. Your template / operator overloading fix the syntax, but I sort of think that's worse, because people may not realize what they're doing will be more expensive than assigning to a double. But the main problem is people now need to pull in your template and the property node headers into places they don't want to. The impression I have is that a bunch of code uses 'tieing' to expose lots of internal variables directly. I'd prefer an explicit 'publishing' phase, i.e calls to setValue. Of course your template works fine too, if you're prefer the syntactic sugar. Frederic BOUVIER wrote : I see your (rather dogmatic) point but I also see here people that are not prepared to follow you. My main point is that if there is an interface, it is supposed to work in all cases and my solution address this point. I realized I may have been more rude than I wanted to be. But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. By rewriting the template a little bit, the pointer can be stored only in the template. People that are using tying are JSBsim people and they want their code works standalone. An alternate template without the property connection can do this with no additionnal cost because functions are short and inlined. I don't consider sugar concise syntax that enforce a rule. Look at the SGPropertyNode_ptr class. There are also operator overloading that are counting reference. You could consider it sugar but do you really prefer to increment or decrement values in the code for the sake of seeing what the code is doing. One another benefit of the template/class approach is that the destructor ensure the call to the untie method. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thu, 2003-02-06 at 01:09, James Turner wrote: On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: excerptexcerptIf 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, excerptI'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it.colorparam,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( x ) is so much worse than my_tied_xPos_float = 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, excerptUmmm...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.colorparam,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. HH 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
Re: [Flightgear-devel] Live property picker
Tony Peden writes: 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? 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. In that case, if we want change events to work, we'll have to do one of the following: 1. Require every module that ties a property to fire an update event whenever the value changes; or 2. Poll tied properties with change listeners attached inside the property system and fire the events when appropriate. I'd be include towards #2, since it would centralize the polling and do it only when actually needed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Frederic BOUVIER writes: But I don't think there is a huge penalty here. Classes that are doing tying now must store the SGPropertyNode as a separated pointer for tying and untying. They don't, actually -- the property manager takes care of storing the node. You just do something like fgTie(/foo/bar, this, Foo:getBar, Foo:setBar); at the start, and fgUntie(/foo/bar); and the end, and for the rest of the time you can pretend the property system doesn't exist. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Live property picker
1. Require every module that ties a property to fire an update event whenever the value changes; or 2. Poll tied properties with change listeners attached inside the property system and fire the events when appropriate. I'd be include towards #2, since it would centralize the polling and do it only when actually needed. I'm not really tuned into this discussion at the moment, but I will say it's giving me indigestion just reading this stuff. Let me add that in JSBSim (and for that matter probably any FDM) just offhand I'd say that almost all of our properties will be changing every single frame. Aircraft state and EOM are dynamic things. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Live property picker
Jon Berndt writes: Let me add that in JSBSim (and for that matter probably any FDM) just offhand I'd say that almost all of our properties will be changing every single frame. Aircraft state and EOM are dynamic things. I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Live property picker
James Turner writes: This was a two hour hack I did to learn a bit more of the code, it was fun to do, and the end result is quite nice. It could use some polish (rounding off some digits), and while performance seems okay I'm worried on 'big' nodes it might be a hit. I'm simply using the propertyNode's changeListener API, so presumable there are some nodes in the tree which are not firing their valueChanged() methods when they should be Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Live property picker
David Megginson [EMAIL PROTECTED] said: Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. Sounds like a better technique would be to just reread the current directory's values once every 5 frames or some such thing. It'd be pretty quick. Actually, every frame wouldn't be bad. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Wednesday, February 5, 2003, at 05:42 pm, Jim Wilson wrote: Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. Sounds like a better technique would be to just reread the current directory's values once every 5 frames or some such thing. It'd be pretty quick. Actually, every frame wouldn't be bad. 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? HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
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
Re: [Flightgear-devel] Live property picker
Jumping in here, just to prove to folks that I'm still alive. :) James Turner wrote: 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. Your heart is in the right place, but you are grossly over-optimizing. If the property picker is on the screen at all, that means it is being drawn: property by property, character by character, quad by quad and pixel by pixel every time the frame is drawn. The extra work involved in querying out the property values pales into ridiculous insignificance compared to the rest of the task. A property read involves at most a few indirections and a printf. Plib's text render (just to pick an example) needs to stitch together every byte of that string into a set of OpenGL calls which then get batched and DMA's to the video card. Noise. This is, however, a truly righteous feature. :) Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner [EMAIL PROTECTED] said: 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? 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. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Curtis L. Olson [EMAIL PROTECTED] said: 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. Yes, good point. I hope you can come up with a method that works, James. This will be a handy tool. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
James Turner writes: 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? 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? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Wed, 2003-02-05 at 17:56, David Megginson wrote: James Turner writes: 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? 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? 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. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Wed, 5 Feb 2003, David Megginson wrote: James Turner writes: 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? 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? I dislike polling. I've seen one too many interface get really bloated because every author believes that his bit of code just contributes a little bit of overhead. With my personal feeling out of the way, there is a drawback to the subscriber approach; if a data feed goes ballistic, so will its subscribers. Polling at least is a deterministic waste of cycles (and cache efficiency and other things we're taught to ignore these days :-) I'm not sure it matters either way, in this case, because I think (based on my limited knowledge of the code) that the overhead really is noise. Someone mentioned sprintf; now _that_'s an expensive piece of code to avoid in a poll run. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
