Responding to all three posts at once... Chris 'Xenon' Hanson wrote:
I think I've used glIntercept before and dfound it pretty useful. What was the motivation in not building on it?
Lack of support for multiple threads, and no obvious way to add that support, was one reason for abandoning it. Also, when I attempted to use GLIntercept with (single threaded) OSG, I encountered problems as described recently in the discussion thread "GLIntercept and OSG 2.8.2" on this list, as if the device driver were launching its own internal thread that called back into itself.
As for BuGLe, there's an obvious bias towards Linux. Also a heavy third party dependency chain (my scheme would have no dependencies other than OSG plugins for optionally writing images). BuGLe also has its own debugging interface, whereas my system would allow the user to set breakpoints and collect backtraces using the debugger they are already familiar with, a much better solution IMO.
I think I've already addressed the performance and maintenance concerns in my first post. To recap, by default, OpenGL calls would go directly into OpenGL. As for maintenance issues, I'd argue that we already have them, and a system like I'm proposing would actually make it easier to add new OpenGL features and extensions, as well as add them in a unified and consistent way.
Anyhow, I just wanted to throw it out for consideration in case others were interested.
-Paul _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
