Simon, How about a NodeVisitor that allows optimal customisation via compile-time polymorphism? It would need a bit of thought as to how to refactor the code, but first I would like to gauge interest. I would be happy to assist if there is benefit to anyone.
We should be able to achieve better customisation with even better performance than the current implementation. I also have some implementations for hooking together general functors to simple free-functions which often eliminates the need to write NodeVisitor derived classes, if anyone is interested. Of course the run-time polymorphism offers greater flexibility and open-ness and should remain, but it can probably be augmented without compromise. Neil Groves On Fri, Nov 21, 2008 at 1:21 PM, Simon Hammett <[EMAIL PROTECTED]>wrote: > Oh. That's awkward. There's no other good way of setting the state in > a node visitor in that case. > > 2008/11/21 Robert Osfield <[EMAIL PROTECTED]>: > > Hi Simon, > > > > I'm not happy with making another very commonly called inline method > > virtual as it will the performance implications are not trivial. The > > methods are deliberately made inline to keep the performance overhead > > to a minimum. For this reason I won't be merging this change. > > > > Robert. > > > > On Fri, Nov 21, 2008 at 12:10 PM, Simon Hammett > > <[EMAIL PROTECTED]> wrote: > >> Hi Robert, > >> > >> Please find attached a modified version of osg/NodeVisitor from trunk. > >> The specific changes are to make virtual both: > >> void pushOntoNodePath(Node* node) > >> void popFromNodePath() > >> > >> The use case for this is to allow derived node visitors to be informed > when > >> the level in the graph changes so they can push & pop their own internal > state. > >> > >> Otherwise there is no good way of knowing that this has happened. > >> I could possibly do something where I try and store a previous parent > >> node pointer > >> and check that within the accept methods but that's butt ugly. > >> > >> -- > >> The truth is out there. Usually in header files. > >> > >> _______________________________________________ > >> osg-submissions mailing list > >> [email protected] > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >> > >> > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > > -- > The truth is out there. Usually in header files. > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
