Hi Martin, On 12 June 2013 13:22, Martin Scheffler <osgfo...@tevs.eu> wrote: > in reference to my submission here: > http://forum.openscenegraph.org/viewtopic.php?p=54555#54555 > > as I said, I simply submitted Vitezslavs patch. I can certainly try to remove > the extra hooks from the osg main classes. > The moveToThread command must be called with the Qt widget and the Qt > graphics thread before makeCurrent is called the first time.
What does moveToThread do? Is it a form of release context? Under Windows the GraphicsWindowWin32::releaseContext() is implemented with a wglMakeCurrent(_hdc, NULL) while X11 has glXMakeCurrent( _display, None, NULL ). The release context is used to make sure that a thread no longer retain a context as being current, allowing it to be made current in another thread. > Another thing I just realized: The code will only work when CMake option > BUILD_OPENTHREADS_WITH_QT is set! Otherwise the static_cast in > GraphicsWindowQt::moveToThread will fail. > How can I solve this? For multithreading to work with Qt5 it seems we need > the render threads to be QThreads. Maybe add a flag to OpenThreads/Config and > #ifdef against that? Oh the joy of a windowing toolkit trying to do everything... It rather does seem like a lot of hoops to jump through, and that we'd need to compile the OSG against Qt, not just osgQt to get things to work. Perhaps one way round would be for osgQt to provide it's own OpenThreads integration, or perhaps for osgViewer to allow the osg::GraphicThread threads to be provided in an more user definable way. Where I'd like to get to is have the core OSG usable directly and independently from Qt, and only osgQt and the Qt examples requiring Qt or a specific version of Qt. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
