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
