Hi again, please find attached a patch against current trunk that fixes my problems.
This patch does the following (in order of the chunks in the patch): - Add a missing include in GraphicsWindowsX11 without which it won't compile on my Mac. - Add a missing include to the osgviewerQt build (taken straight from src/osgviewer/CMakeLists.txt) - Ensure GraphicsWindowsCarbon::WindowData is used with QOSGWidget for Mac builds even on 10.4 and 10.5. Without this change, the widget will use the X11 WindowData struct but the peer will expect a Carbon WindowData struct, leading to a segfault. I'm not sure this is the right fix - it might have to pay attention to other configure-time variables. (I.e. it might not work if you asked for using the X11 peers instead of the carbon peers at configure time) - Extract a WindowPtr from the HIViewRef that QWidget::winId() returns. Without this change, the peer tries to call GetWindowPort on the HIViewRef which returns 0. This was the reason that the window remained white. - Setup the camera only after ViewerQOSG's Qt base class has been initialized. Without this change, the view is wrong (doesn't cover the whole window). - Open the ViewerQOSG window at 30/30 instead of 0/0. When opened at 0/0 it lacks any window decoration (not sure why that is so - might be a Qt "feature"?) I hope this helps. Cheers, Julian On Fri, Oct 31, 2008 at 12:26 PM, Julian Scheid <[EMAIL PROTECTED]>wrote: > Hi, > > OK so I figured out that my problems are due to using AdapterWidget - I > understand that shadows etc. should work fine with QOSGWidget. > > Unfortunately QOSGWidget doesn't work here: the widgets remains white and > Qt prints warnings about recursive repaint. > > I've checked out the latest OSG trunk and tried with that but get the same > result (actually it segfaults due to a bogus ifdef in the QOSGWidget source > code - I'll send over a patch shortly - but after fixing that I get the same > result.) > > I've started tracking down the problem, so far the only thing that I > figured out is that GetWindowPort always seems to return 0 for the > QOSGWidget's native peer - is that expected? > > I'm using Qt 4.4.3 on an Intel Mac with OS X 10.5. The Carbon code paths > are used, not X11. Are there any known problems with QOSGWidget with Qt > 4.4, OS X 10.5 or with the Carbon peers? > > Thanks in advance, > > Julian > > > > On Thu, Oct 30, 2008 at 3:30 AM, Julian Scheid <[EMAIL PROTECTED]>wrote: > >> Hi, >> >> I'm trying to embed osg in a Qt4 application. I've had some troubles with >> FSAA/multisampling but managed to work around it by configuring the >> QGLWidget for FSAA instead of osg. >> >> However, I'm now trying to get shadows to work based on the osgshadow >> code, and it seems that no matter which shadowing technique I try it brings >> my machine to a grinding halt - the whole screen starts to flicker wildly, >> circles and balls reminiscent of Katamari Damacy are drawn into the scene, >> and when continuous update (via timer) is enabled I have no recourse but to >> restart my machine. (This is one of the new Intel Macbooks running OS X >> 10.5) >> >> I gather that when embedded in Qt, the GraphicsWindowCarbon code isn't >> used and osg just uses the existing GL context. Does that mean that I would >> have to manually setup Qt's GL context and somehow synchronize it with osg's >> shadow magic? >> >> If all that is meant to be supported in the Qt viewer, is there any chance >> you could add an example for this situation? >> >> Thanks in advance, >> >> -Julian >> >> >
osg-qosgwidget-osx.patch
Description: Binary data
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
