Qt-interest Archive, July 2007
Graphics View Framework
Message 1 in thread
Hi everyone,
My goal is to make a graphical 2D simulator using QT. The graphics view
framework seems like a good fit for this application, as I have to track
hundreds or thousands of independent entities that may at some point
interact with the view. The documentation states that the framework itself
can support millions of items.
I found the collidingmouse example (examples/graphicsview/collidingmouse)
to be interesting and relevant to my goal. By default, the example only
manages/renders
7 mice. I experimented with increasing the number of mice to 100, and
observed that the program lagged quite a bit. In some cases, it would
render a couple frames per second under Linux on a fast processor. The
bottleneck appears to be the rendering of the mice actively visible in the
view. In other words, if there's 100 mice in the scene, but only 10 of them
are visible in the window, then there is no noticeable slow down.
The example seems inefficient in the sense that it must completely redraw
the mouse each time the item's paint() routine is called. It also has an
independent timer for each mouse in the scene to update the view. I'm also
not sure if the timer is inefficient compared to the QGraphicsItemAnimation
strategy mentioned in the documentation.
I was curious if someone out there understands why this program doesn't
scale well, and might have some suggestions to how it can be reimplemented
for efficiency. In particular, it seems there must be a way to 'compile'
the mouse drawing, so the complicated rendering procedure only has to happen
once.
I tried enabling OpenGL support in the example, as suggested by the
documentation:
view.setViewport(new QGLWidget(QGLFormat(QGL::SampleBuffers)));
This did improve performance marginally in some circumstances (I have
hardware acceleration), but actually hurt performance in others. In
particular, it slightly improves performance for the case where all 100 mice
are active in the view, but hurts performance for the case where only a
small number are visible. I imagine the performance regression is related
to GL call overhead, which normally doesn't take place for the case where
mice are not visible in the scene.
Is it possible to have hundreds of simple, active sprites in a view (given a
decent processor), or am I better off writing this application natively in a
QGLWidget?
Thanks in advance for any suggestions people have.
Mike
Message 2 in thread
Mike Bohan wrote:
> I was curious if someone out there understands why this program doesn't
> scale well, and might have some suggestions to how it can be reimplemented
> for efficiency. In particular, it seems there must be a way to 'compile'
> the mouse drawing, so the complicated rendering procedure only has to
> happen once.
Firstly, Graphics View doesn't make everything fast. You can't implement
slow rendering through a QGraphicsItem and expect it to be fast; with or
without OpenGL. Graphics View provides a framework that can maintain
millions of items efficiently, and it does what it can to make item
discovery and collision detection fast. When it comes down to rendering,
there's nothing Graphics View can do to speed that up.
Now, this particular example isn't there to show off how Graphics View
scales to support millions of items; it's there to show how to implement
animations and collision detection for simple items. See the example docs
for details. There are several things about this example that don't work
well for a large number of mice. That's also why it only shows 7.
Why does it completely redraw the mouse for each frame? Because that's how
Graphics View works; it renders pixel-perfect 2D shapes. If you magnify a
mouse, you'll see that the rendered output is of very high quality. If you
don't want this, you can easily add tricks to QGraphicsItem's paint()
function - you can even use raw OpenGL if you want.
If you want to see an example that shows how to render lots of items fast,
you should try the 40000 Chips demo.
--
[ signature omitted ]
