Hello Robert,
> The secondary role of OSG examples is also to act as a unit test, here
> adding extra viewer functionality can help with testing, but this is
> something we should only add if there is a real need for this extra
> functionality, and done on a case by case decision.
I can see your motivation, but I would argue the "case by case" part. In
the spirit of unit testing, I think it would be useful to know, for all
examples:
a) what the performance impact of a feature is (StatsHandler)
b) if it's thread-safe (ThreadingHandler)
c) if it plays well with state changes (StateSetManipulator)
d) if it has problems when the window size changes or when the app goes
fullscreen (WindowSizeHandler)
and then fix all issues (if there are any). I think it's kind of a
minimum set of cases where an example must work correctly for it to be
usable in other contexts (more complex apps).
In addition, a user evaluating OSG would appreciate a consistent set of
viewer features across all examples, and these features would help in
evaluating if OSG will work for them.
And adding each handler is one line of code, so say 4 lines total, and
is self-documenting. Even the argument parser stuff which is in every
example dwarfs this in number of lines of code, and is also harder to read.
But beyond any philosophical arguments, adding the handlers and testing
them would have brought up the issue when changing the threading mode in
osgShadow a bit sooner. Who knows what other examples also have an issue
when changing the threading mode?
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
