Andreas
Qt
Labs
Graphics View
Graphics Items
Posted by Andreas
 in Qt, Labs, Graphics View, Graphics Items
 on Tuesday, February 27, 2007 @ 19:12

We’re in the process of closing up the features for 4.3, and I’ve had a little run-down of what’s changed in Graphics View.

In general, you will notice that the graphics run faster, (especially for complex polygons,) collisions are absolutely precise, the rubberband looks 100x better… I think most of our Graphics View followers will be very pleased with the upcoming Qt 4.3.

When the first beta is released, it’s nice if you as a Graphics View developer try out your Qt 4.2 app with 4.3, so that we can nail out any possible regressions (both behavior and speed) before the final version is out. So please, let us know :-).

Here are some of the new features:

  • QGraphicsView has some new properties.
    • viewportUpdateMode: Now you can fine-tune how the viewport reacts the changes in the scene.
    • rubberBandSelectionMode: For those who want to select items that are inside but don’t intersect with the rubberband…
    • optimizationFlags: If you want faster graphics, away goes the safety net… ;-)
  • All flicker in rubberband mode is gone.
  • You can also transform the view with a QTransform; this works best for small scenes, though. But the effect of seeing your scene with perspective transformations is pretty cool.
  • QGraphicsItem has some new flags.
    • ItemClipsToShape: All item rendering is clipped to its own shape
    • ItemClipsChildrenToShape: Like widgets, the parent item clips all its descendents.
    • ItemIgnoresTransformations: The lovable item that just won’t transform… well.

There’s been some under-the-hood changes too. Where before, if you moved an item, it would always get continuously reindexed (for each mouse move event), now it goes into an intermediate state that keeps the item outside the index until you leave it for a while. When moving a lot of items together, this makes a huge difference. It also means you don’t have to use NoIndex for scenes that combine animated and static items! It’ll still be pretty fast.

Check out the chip demo, or run the Colliding Mice example in one window, and top/Task Manager in the other; it’s faster in Qt 4.3 snapshots!

[no carrier] - /me waits for the first comment going “Hey, it’s not fast at all!” ;-)

21 Responses to “Graphics View improvements”

» Posted by yannick
 on Tuesday, February 27, 2007 @ 20:12

when do you think the first beta will be released ?

» Posted by anon
 on Tuesday, February 27, 2007 @ 20:16

Hey, it’s not fast at all :)

From 20070225 snapshot…

Scaling of pixmaps seems slow to me. Especially when scaling with a factor

» Posted by anon
 on Tuesday, February 27, 2007 @ 20:18

… err Especially when scaling with a factor

» Posted by anon
 on Tuesday, February 27, 2007 @ 20:18

buggy comments

» Posted by Marius
 on Tuesday, February 27, 2007 @ 20:40

anon: You mean a factor of either 1) < 1.0 2) > 1.0?

» Posted by Leo S
 on Tuesday, February 27, 2007 @ 20:49

Great! All those speed improvements apply directly to the app I’m writing. Can’t wait to try it out.

» Posted by anon
 on Tuesday, February 27, 2007 @ 21:09

Marius, I mean a factor less than 1.0. Try this…

Add some pixmaps to the portedcanvas example. Specifically, add about 5 really big pixmaps. Say the size of your screen. Then animate them scaling down to thumbnail size all at the same time. Very slow.

» Posted by anon
 on Tuesday, February 27, 2007 @ 21:11

Btw, they don’t have to be anywhere near that big. It’s just most dramatic ;)

» Posted by Dominic
 on Wednesday, February 28, 2007 @ 00:16

Could you post a screenshot of the hot new rubberband? I am curious…

» Posted by Steve
 on Wednesday, February 28, 2007 @ 04:12

Could you post a screenshot of the hot new rubberband? I am curious…
I don’t think the rubberband was changed…there was just a bug fix for it.

» Posted by Theo
 on Wednesday, February 28, 2007 @ 07:53

I saw some rubberband problems in 4.2 when using OpenGL on Windows. These have been fixed in 4.3 and is is definitely a lot quicker. Unfortunately the fix won’t work for my own rubberband which I use for rectangle zooming.
The 4.3 version is on Windows a lot quicker. So far, times went from 15 minutes per paint event back to 22 seconds. But we have not yet fully implemented our graphics editor. Wait and see if it can handle 1+ million polygons.

» Reply from Andreas
 on Wednesday, February 28, 2007 @ 08:36
Andreas

The rubberband looks awesome with and without OpenGL (yes, the strange painting errors are all gone), and all flicker is gone. A screenshot wouldn’t really show you what’s improved; it looks just like in 4.2 (still follows the style), but without the rendering errors, and without flicker when you move it around. It feels faster too, and that’s not just because the implementation has improved. It’s also because of Zack’s efforts to speed up shape intersection, and some other cool cut-offs we’ve implemented.

Scaling pixmaps has always been slow on X11. Is it slower now than before? /me goes and bugs the other graphics guys.

» Posted by anon
 on Wednesday, February 28, 2007 @ 16:34

If it helps, yes I think the scaling down of large pixmaps is slower than usual on X11, but I have no actual metric of interest.

» Reply from Andreas
 on Wednesday, February 28, 2007 @ 17:37
Andreas

If you show us metrics, we might be able to fix it. Without metrics, there’s little we can do.

» Posted by Thomas
 on Tuesday, March 06, 2007 @ 14:24

Hi,

I just checked the performance of the colliding mice demo - and it seems to be quite the same on my machine!
heres an example of 4.3-snapshot (28.02.2007 -btw. there are no snapshots of march???)
51.9 X
38.4 collidingmice

(without any window resizing etc.)

anything I can do about it?

Thomas

» Reply from Andreas
 on Tuesday, March 06, 2007 @ 15:48
Andreas

Which platform?

» Posted by Jeremy Friesner
 on Wednesday, March 07, 2007 @ 06:27

Just curious about the ItemIgnoresTransformations flag…. in my app I allow the user to zoom in, which causes everything to be larger, including the text labels. Having big 50-point text labels isn’t terribly useful, and it would be nicer if the text always stayed the same size while everything else magnified as usual. (The text’s location would need to stay the same relative to the other content, of course) Will this flag help me in that regard?

Thanks,
Jeremy

» Posted by Thomas
 on Wednesday, March 07, 2007 @ 07:50

Hi Andreas,

I tested on a SuSE Linux 8.1 (I know old stuff - but that should not influence the performance?), using a GCC 3.2 and Xfree 4.3

Best regards,

Thomas

» Posted by Diego
 on Wednesday, March 07, 2007 @ 11:00

Jeremy,

I have solved a similar problem (some labels and rectangles need to stay the same size regardless of the zoom factor, however it needs to react to other transformations such as translation), and so far I have solved using a combination of signals triggered when a zoom-in / zoom-out is applied. However, I would like to have a more elegant way of doing so, and I expect that new flag to help me with that task. Andreas, perhaps instead of just one flag (ItemIgnoresTransformations) could it be extended so we can have several independent flags (ItemIgnoresRotation, ItemIgnoresScaling, …)?

Best regards,
Diego

» Posted by Rajesh
 on Wednesday, March 07, 2007 @ 11:19

I reported a bug in Qt4.2.0
that the background is not drawn completely when you do not call setSceneRect()
Is this bug fixed?

Best regards,

Rajesh

» Reply from Andreas
 on Wednesday, March 07, 2007 @ 19:15
Andreas

Jeremy: Yes! This is exactly what the flag does for you.
Diego: No signals necessary, just set this flag. If you need more than this, please file a suggestion.
Rajesh: Have you tried 4.2.3? 4.3.0? 4.4.0? All reported bugs have been fixed for 4.3.0.



© 2008 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners.