Hi Lukas,
I'm not a QT expert so I can't provide a definitive word on this
topic, I can provide a couple of high level guides though.
First up, running multiple windows multi-threaded will give you the
best performance, the OSG is designed for this usage model, and most
easily set up using the native windowing support that the OSG
provides.
When you want to integrate the OSG with other windowing toolkits you
have several routes, and revolves around providing a custom
GraphicsWindow implementation that provides the glue between your
windowing toolkits graphics/context window and the viewer classes.
The simplest way to glue a viewer into an existing window is the
GraphicsWindowEmbedded, and this means you don't even have to subclass
from GraphicsWindow, you just set the viewer with an embedded context
and start calling frame on the viewer. There are constraints to this
though - GraphicsWindowEmbedded is really just a mock integration
layer, it doesn't actually provide any functionality, it's all non
ops, and is just a mechanism for fooling the Viewer and
CompositeViewer classes into believing that they do all the swap
buffers and make current calls on the context, but in reality they do
nothing, and these must be provided by the calling code. The
osgViewer multi-threading and multi-window ability actually comes from
the ability to do swap buffers and make current so if you don't have
this then you're Viewer/CompositeViewer looses this ability. So it's
a very simply approach, but quite limiting with it - it's fine for
viewers where each window has its own scene graph, and run
independently from all other windows and can happily run event driven.
The more complex but for more functional route is to implement a
GraphicsWindow subclass that provides the glue between the osgViewer's
requirements and the windowing toolkits support. You can do this by
inheriting the window toolkit's window and letting the OSG create the
graphics context, or you can adapt the window toolkits window with
graphics context into the what the OSG can use. Generally the window
inheritance will probably be the best route as most window toolkits
have rather poor OpenGL support - lacking full pixel formats/stereo
and pbuffer support.
When looking back over the archives I'd suggest putting the most
weight on recent posts, rather than ones written over a year ago, as
the osgViewer was still very young back then, even now it's still a
but of youngster at only a year and half old. Developments do
continue, and in particular I'd like to see us provide better base
level integration with 3rd partying window toolkits - for instance
moving Qt, WxWindow etc integration into include/osg/Viewer/api. When
this will actually happen is hard to say as it's dependant on the
availability of my own time and others in the community that have
expertise on the various toolkits. You are welcome to join in with
this effort of shaking down 3rd party window toolkit integration.
Robert.
On Wed, Oct 8, 2008 at 1:21 AM, Lukas Diduch <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> i have touble with the performance of my QT-Application (Qt 4.2, OSG
> 2.4.6). It embeds multiple osgViewers based on the the QGLWidget from
> the svn. I would really appreciate some points in the right direction.
>
> First of all i have to say that i've done this stuff already as a pure
> GL implementation as well as a mix of QT-Gl which runs pretty well in
> both cases. Trying to port the App to OSG though introduces some
> trouble.
>
> A side note: The aim is to have multiple views of independent scenes
> in one QT app. This is due to reasons of rising demand of modularity
> (widgets for data models are easy to integrate) as well as reusability
> of the gui elements of QT4, like menus and sliders.
>
> I experience degrading performance the more views are integrated into
> the application. No memleaks though. The App runs in all cases at 5-10
> % CPU max. which should (in my experience) actually rise at least a
> little with the rising number of views. The rendering definitly slows
> down, and same for the event-handling (mouse inputs gettin jittery/
> lost).
>
> A quote in a similar matter:
>
>> Re: [osg-users] Memory leaks with QT and multiple osg::Viewers
>>
>> Robert Osfield
>> Tue, 12 Jun 2007 03:26:45 -0700
>>
>> First things first, GrpahicsWidowEmbedded only works with
>> SingleThreaded mode. If you want multi-threading then don't use QT
>> for creating the windows.
>
> Do i need multi-threading to render multiple independent views on the
> OSG end ? Am i touching some common OSG component which makes me want
> to use multi-threading. I think as long as i'm not sharing scenes in
> multiple views i should be fine. My !OSG apps don't use
> multi-threading and are running quite fine (derived QGLWidget using a
> slot to pass a pointer to the raw-data and a call to updateGL (with a
> datarate is about 50 fps)).
>
> Basically (after 2 days playing around) i have the feeling the event
> queue handling (qt's or osg's) is responsible for the degraded
> performance and it should be quite possible to do this right somehow
> with a splendid performance.
>
> Am i better off using the QGLWidget or the QWidget implementation of
> the example if i want to implement this ? (couldn't get the QWidget
> thing to run multiple views embedded in separate widgets)
>
> Should i write a new Viewer class ? (something like Composite Viewer)
> or
> Should i play with a shared osg-event-queue among the OSGQTWidgets
> first ?
>
> Since the documentation on the osg codebase is quite sparse i'm having
> trouble to find a reasonable starting point without reading all the
> code.
>
> Any ideas or/and recommendation are very welcome.
>
> Lukas
>
>
> // Here's some quick-hack code to demonstrate the problem and play
> // around a little. It's using the svn examples AdapterWidget.cpp of
> // the OpenSceneGraph/examples/osgviewerQT. Don't forget to build
> // with -DUSE_QT4 since we're talking about qt4 here.
>
> #include <QtGui/QApplication>
> #include <QtGui/QtGui>
> #include <QtGui/QWidget>
>
> #include "AdapterWidget.cpp"
>
> #include <vector>
> #include <iostream>
>
> using std::vector;
> using std::cout;
> using std::endl;
>
> int main ( int argc, char **argv )
> {
> QApplication a ( argc, argv );
>
> if (argc<2)
> {
> std::cout << argv[0] <<": requires filename argument." <<
> std::endl;
> return 1;
> }
>
> osg::ArgumentParser arguments (&argc, argv);
>
> // load the scene.
> osg::ref_ptr<osg::Node> loadedModel = osgDB::readNodeFiles
> (arguments);
>
> if (!loadedModel)
> {
> std::cout << arguments[0] <<": No data loaded." << std::endl;
> return 1;
> }
>
> int nbCowsX = 2;
> int nbCowsY = 2;
>
> vector <QWidget*> vWidgets;
> vector <ViewerQT*> vViewers;
> QGridLayout *uiLayout = new QGridLayout ();
>
> for (int x=0;x<nbCowsX; x++)
> for (int y=0;y<nbCowsY; y++)
> {
> QWidget *tmpW = new QWidget ();
> ViewerQT* tmpV = new ViewerQT (tmpW);
> tmpV->setGeometry(0,0,200,200);
> tmpV->setCameraManipulator (new
> osgGA::TrackballManipulator);
> tmpV->setSceneData (loadedModel.get ());
> uiLayout->addWidget (tmpW, x,y);
> vWidgets.push_back (tmpW);
> vViewers.push_back (tmpV);
> }
>
> QWidget w;
> w.setLayout (uiLayout);
> w.resize (nbCowsX * 200, nbCowsY * 200);
> w.show ();
>
> vector <ViewerQT*>::iterator it = vViewers.begin();
>
> for (;it < vViewers.end (); it++)
> {
> ViewerQT *t = *it;
> t->resize (200,200);
> }
>
> a.connect ( &a, SIGNAL (lastWindowClosed ()), &a, SLOT (quit ())
> );
>
> return a.exec ();
> }
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
