Hi Don, I tried your change to use DrawThreadPerContext but I get crashes in the ATI driver. I don't know if this is an ATI bug or a bug in the way that the custom GraphicsWindow has been implemented. I will need to some more testing of standard osgViewer apps when running multi-threaded, multi-window.
On the flickering front I found out that I only get flickering if I have the KDE desktop effects enabled, disable them and the window behaves just fine. Robert. On Fri, Jun 19, 2009 at 5:49 PM, Don Leich<[email protected]> wrote: > Hi Robert, > > I'm glad to see this is going main stream. There is some low hanging fruit > in > finding better performance, namely selecting a threading model better than > single. The small changes attached should do that, but I'm curious why the > performance is so exceptionally horrible in the SingleThreaded model. > > The flashing/flickering can to some degree be mitigated by some QWidget > attributes. I don't know how many times I've read these and I still don't > understand what all they imply, but distilled down, setting either of the > first 2 suppresses clear color painting by Qt to varying degrees. The 3rd > seems to disable some sort of swap buffer equivalent, hence the note it > disables double buffering. The best combination seems to be > Qt::WA_OpaquePaintEvent and > Qt::WA_PaintOnScreen (which may be X11 only) and not > Qt::WA_NoSystemBackground, > although these settings may be platform or driver specific. > > Any experimentation and testing is welcome! > > -Don > > > From Qt doc... > > Qt::WA_NoSystemBackground > > Indicates that the widget has no background, i.e. when the widget receives > paint events, the background is not automatically repainted. Note: Unlike > WA_OpaquePaintEvent, newly exposed areas are never filled with the > background (e.g after showing a window for the first time the user can see > "through" it until the application processes the paint events). This is > set/cleared by the widget's author. > > > Qt::WA_OpaquePaintEvent > > Indicates that the widget paints all its pixels when it receives a paint > event. It is thus not required for operations like updating, resizing, > scrolling and focus changes to erase the widget before generating paint > events. Using WA_OpaquePaintEvent is a small optimization. It can help to > reduce flicker on systems that do not provide double buffer support, and it > avoids the computational cycles necessary to erase the background prior to > paint. Note: Unlike WA_NoSystemBackground, WA_OpaquePaintEvent makes an > effort to avoid transparent window backgrounds. This is set/cleared by the > widget's author. > > > Qt::WA_PaintOnScreen > > Indicates that the widget wants to draw directly onto the screen. Widgets > with this attribute set do not participate in composition management, i.e. > they cannot be semi-transparent or shine through semi-transparent > overlapping widgets. This is only supported on X11. On Qt for Embedded > Linux, the flag currently only works when set on a top-level widget and > relies on support from the active screen driver. The flag is set or cleared > by the widget's author. For rendering outside of Qt's paint system; e.g. if > you need to use native X11 painting primitives, you need to reimplement > QWidget::paintEngine() to return 0 and set this flag. Note: This flag > disables double buffering. > > > > Robert Osfield wrote: >> >> Hi Don et. al, >> >> First up thanks to all for helping getting this example ready for >> integration with the OSG as an example. I've just merged the new >> example into svn/trunk and get it compiling quite easily. I just had >> to fix a couple of superfluous ; that were causing warnings and tweak >> the name to be more consistent with other viewer examples - I've >> called it osgviewerQtWidget to differentiate it from the existing >> osgviewerQt example. I haven't update the .pro file or the READEME, >> as we go forward my expectation is that these can be tweaked to >> reflect the new naming (I'm open to suggestion of further name changes >> for this example.) The example is now checked into svn/trunk. >> >> I've done some testing of the new example of my Kubuntu 9.04 (with Qt >> 4.5) and my ATI card and find the performance to be pretty poor and >> the sub windows within the window with the 4 views flickers for all >> but the top left sub window. I've not reviewed the code itself yet so >> can't comment on how to solve these problems. Hopefully the community >> will be able to pitch in. >> >> Cheers, >> Robert. >> >> >> On Thu, Jun 18, 2009 at 10:05 PM, Don Leich<[email protected]> wrote: >> >>> Loic/Robert, >>> >>> Now that I've solved my cmake problems (grrrrr) I have a cleaned up >>> version >>> of the qosgwidget example. This has a change to QWidget rendering >>> attributes >>> that Eric Pouliquen recently recommended that, with my own variation, >>> seem >>> to >>> be an improvement over what is in osgviewerQt. It also has another >>> change >>> or >>> two which were the results of actually reading some Qt Doc! >>> >>> Let me mention that this example runs much slower in SingleThreading than >>> in the other threading modes. The same is true for >>> >>> osgviewerQT --QOSGWidget --CompositeViewer cessna.osg >>> >>> This is something I still don't understand. >>> >>> -Don Leich >>> > > // CompositeViewerQOSG.cpp > > // #include <QCore/QDebug> > #include "CompositeViewerQOSG.h" > > //////////////////////////////////////////////////////////////////////////////// > CompositeViewerQOSG::CompositeViewerQOSG( QWidget * parent, Qt::WindowFlags > f) > : QWidget( parent, f ), osgViewer::CompositeViewer() > { > // setThreadingModel(osgViewer::CompositeViewer::SingleThreaded); > setThreadingModel(osgViewer::CompositeViewer::DrawThreadPerContext); > > // update schedules a paint event when returns to the Qt event processing > loop. > // Prefered to repaint which causes an immediate paint event. > connect(&_timer, SIGNAL(timeout()), this, SLOT(update())); > > // Doc claims most platforms can reliably do 20 milliseconds. > _timer.start(1); // Qt should silently ignore ticks it's unable to keep > up with. > } > > > void CompositeViewerQOSG::paintEvent( QPaintEvent * /* event */ ) > { > frame(); > } > > > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
