Hi Lukas,
Keep posting on this topic as it provides us all with some extra
knowledge about what works/what doesn't etc. Also modify the
osgviewerQT example with mods if you want others to test out what you
are playing with.
Cheers,
Robert.
On Tue, Oct 14, 2008 at 9:59 PM, Lukas Diduch <[EMAIL PROTECTED]> wrote:
> Hello Robert,
>
> after digging deeper into the interna of GraphicsWindowX11.cpp i've
> found a pretty simple hack to use OSG (natively) in QT with
> CompositeViewer in multithreded mode. Natively means with a graphics
> context created by OSG.
>
> The hack is basically tweaking QOSGWidget from the examples by
> readjusting the window parameters (x,y,width, heigth) AFTER the context
> has been created AND giving the QOSGWidget it's proper parent widget.
>
> Something like:
>
> // before creation of context
>
> osg::ref_ptr<osg::GraphicsContext> gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
> _gw = dynamic_cast<osgViewer::GraphicsWindow*>(gc.get());
>
> // after creation of context
>
> traits->x = x();
> traits->y = y();
> traits->width = width();
> traits->height = height();
>
>
> It's that silly but solves the problem :) You will get a BadWindow error
> from X_GetWindowAttributes though, see later.
>
> Looks like GraphicsWindowX11 is somehow capable of window inheritance
> afterall (since the winIds of the toplevel QWidget's children are used,
> which are SubWindows of the Toplevel window).
>
> The problem are following 5 lines in the GraphicsWindowX11 code at the
> end of setWindow :
>
> 749 XWindowAttributes watt;
> 750 XGetWindowAttributes( _display, _window, &watt );
> 751 _traits->x = watt.x;
> 752 _traits->y = watt.y;
> 753 _traits->width = watt.width;
> 754 _traits->height = watt.height;
>
> The call to XGetWindowAttributes fails with BadWinow and the watt values
> become completely messed up. This results later in :
>
> Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
>
> As you can see only the traits values of the context are getting messed
> up and 'resetting' them afterwards solves the problem.
>
> Unfortunately i'm not an X11 expert so i wonder why we get a BadWindow
> in the first place since we get a proper (X11) windowId from QT. A call
> to any X function inside the QWidget (with its own windowId) fails as
> well with a BadWindow ! It seems to me that some call is missing in
> order to get the Window Hierarchy straigt. Which call it is which has
> not been executed at this point would be very interesting since then
> XQueryTree could be used inside setWindow for window inheritance
> features.
>
> I will keep you posted on any more interesting stuff.
>
> best regards
> Lukas
>
> On Wed, Oct 08, 2008 at 11:22:15AM -0400, Lukas Diduch wrote:
>> 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
>
> --
> 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
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
