Hi Robert,
thanks for the reply. That gives me a really good starting point and
overview for further development. I don't know how much effort i can put
into subclassing GraphicsWindow to interface between QT and OSG to do a
clean base for further integration since i'm not an expert in both of
these, but i will keep you guys posted on any positive outcome.
Greetings
Lukas
On Wed, Oct 08, 2008 at 09:38:34AM +0100, Robert Osfield wrote:
> 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
--
Lukas L. Diduch
Smartspace Laboratory
Information Access Division (IAD)
National Institute of Standards and Technology (NIST)
web : http://www.nist.gov/smartspace
email : [EMAIL PROTECTED]
office : +1 (301) 975 6399
fax : +1 (301) 975 5287
mobile : +1 (240) 899 6536
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
