Light items for the graphicsView

Hi guys,

I am using the GVFramework and need to create some "light" items. (rect item showing some image(consiting of some lines). It looks fine, but after adding 100 items or even less, when I move the cursor my CPU usage reaches 100, as if the scene was doing a full repaint. Those items should be drawn and nothing will be changed(in that items) after creating them. I just need to be able to create them/show on the scene/ add remove them.
Still when my own custom item(100 of them) my scene works slow.
Some code:

Code:

---

///item derived from QGraphicsRectItem has those settings in the constructor
setAcceptDrops(false);
setEnabled(false);
setAcceptsHoverEvents(false);
setAcceptedMouseButtons(false);

---

I will need to add more then 100 000 items in the future. (I know that it is said that "up to milions of items can be used", but how to make it work fast)

Thanks for any advice.

Maverick

render the graphics view with opengl.

view->setViewport(new QGLWidget) ?

By default, QGraphicsView provides a regular QWidget for the viewport widget. You can access this widget by calling viewport(), or you can replace it by calling setViewport(). To render using OpenGL, simply call setViewport(new QGLWidget). QGraphicsView takes ownership of the viewport widget.

Yep!

Yes I know that, but after including the headers (ading QT+=opengl) in the pro. when I compile(it ok, no errors) and run it I get unhandled exception in this line:
m_view->setViewport(new QGLWidget).

: )

hmmm....
me not....
where do you call it?
bevore initialisation of your view, or bevore setupUi() ??

I have added that line just after creating the view, after setting all the data(scene), etc. but still it crashes just 1 sec after the app starts to run.
Just run it in the debug mode, and the line is not invoking the error directly(because while running) compiler goes smoothly through that line, but then crashes after a sec.

Maverick

Even if you are not using OpenGL, rendering 100 simple items shouldn't be a problem at all. Chances are you are doing something wrong. Try adding 100 pixmap items and see if that's slow. If not you need to show us some code, or at least a screen shot of the kind of scenario you are creating (how big images. how many are visible at the same time...).
And another thing. Why is moving the mouse slowing down your app? Are you reacting on hover events?

Quote:

---

Originally Posted by kernel_panic

render the graphics view with opengl.

---

No no no no no!

OpenGL is not a hammer that you can hit things with to make them faster.

This thread reminds of one on the old qt forum site (forget the name). Someone was complaining that drawing an image was taking a couple seconds and how to make it faster. Same as here, there were several posts saying to just use OpenGL to fix it. Well something smelled fishy with that (why so slow to paint in the first place?), so after some prodding it turned out the original poster was painting his image by iterating through each pixel one by one instead of using drawImage.

Same with this situation. 100 elements should be fast. OpenGl will just mask the real problem. I suspect there is some image scaling going on on hover events or something. We need more information to diagnose the real problem, but rendering with OpenGL is the absolute last ditch resort, if every other avenue is exhausted.

Why? Using an OpenGL viewport removes the single-most expensive operation on any platform (especially X11), which is transformed pixmaps. And that seems to be exactly what he's having problems with. OpenGL offloads your CPU and moves graphics ops onto your otherwise idle graphics card. Contrary to what you're advising, OpenGL should be the de facto choice if you want high performance graphics. Period.

OpenGL is an option, but it should be the last thing you do. If 100 items is slow, you are _probably_ doing something fundamentally wrong. While OpenGL may hide the symptoms, you're not really fixing anything, and people without an accelerated graphics card will be SOL. Especially the stated symptom of 100% cpu usage when moving the mouse indicates there is something seriously wrong in his code and OpenGL is not going to fix that problem, even though his graphics card might be able to handle the insanity.

PS. I can't believe I'm arguing with a Trolltech software engineer about this (hehe, maybe I'm wrong after all).

100 medium-sized pixmaps transformed on X11 is insanely slow on a 3GHz machine even with a top-of-the-notch graphics card. ;-) That's how X11 works, it does not support server-side pixmap transformations. Qt has to download the image, transform the image locally, then _upload_ the transformed pixmap over the X11 connection and ask X11 to draw it. So let's say you have a 256x256 32bit image, which takes up 256KB of memory, transformed it might take up much more, multiply by 100 and you get at least 25 megabytes of data that's transferred to and from the X11 server for every frame. It'll be slow, that's how it is. With OpenGL, it'll be fast. It'll actually be so fast, your CPU is likely to be 99% idle while rendering. If you can use OpenGL, you should. And there's close to no cases where you can't... ;-)

Ok, if you were animating this scene with every object being transformed I see how it would be slow. But the original poster says that cpu usage goes to 100% just by moving the mouse. Does moving a mouse over a scene trigger a full repaint of all objects? Doesn't sound likely...