-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Osfield wrote: > Hi Tim, > > On 5/6/07, *Tim Moore* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > I've gone a little way down this road, creating an extremely minimal > GraphicsWindowSDL that can't even do its own window creation or event > processing. It seems to work pretty well, after some minimal testing. > > > > Cool. Is this what you have attached? Would it be possible to use this > to evolve the OSG's osgsimpleviewerSDL example? Yes. What I've attached is the osgsimpleviewerSDL example, hacked to use the nascent GraphicsWindowSDL class. That class should probably be able to create windows and do event processing before this becomes a real OSG class and example, but the ability to use an externally constructed surface is important for my needs.
> > However, I see a problem with the StatsHandler, the use of which is my > entire motivation for doing this. The stats handler works in > SingleThreaded mode, but in DrawThreadPerContext, which seems to be the > default on a two processor machine, I get: > > Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test > failed, requires valid graphics context. > Segmentation fault > > As far as I know, SDL doesn't have a notion of changing graphics > context > - -- there's only one, that created with the rendering surface -- so I > created a dummy method for makeCurrentImplementation. Is it actually > necessary for the graphics context to be available outside of the > thread > that implements draw? > > > In DrawThreadPerContext the rendering has its own thread, while event, > update, cull traversals are all done in the main thread. The problem > with SDL is that its a bit brain dead when it comes to multi-threaded > usage, let alone multiple window usage. SDL could support it with a bit > of developement. > > It would probably be quicker just to add the missing features to > osgViewer as its graphic window support is far more capable. I'm doing this in the context of an application -- FlightGear -- that is already using SDL and OSG at the SceneView level, and I thought this would be the quickest route to getting the OSG statistics display going in FlightGear. I'm a little surprised to find that threads other than the rendering thread need to access the graphics context; actually, I'm more surprised that DrawThreadPerContext works at all with SDL, if that is true :) It would be nice to support the multi-threaded modes in FlightGear eventually, and perhaps it would be sufficient to supply some platform dependent code in GraphicsWindowSDL to get the current window and context so that it can be made current. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGPYp9eDhWHdXrDRURAibDAJ9EnMYCD4ekosNneebLA9U/Bv5ORgCfSyRv w2SgGNk8WCNSRXDJYrtAIrE= =oY0d -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
