A GraphicsView sneak-peek

Published Monday May 1st, 2006
23 Comments on A GraphicsView sneak-peek
Posted in Graphics Items, Graphics View, KDE, Labs, Qt

Hi, everyone!

I’m back in Norway now, after having been all over (half) the world, talking about threads and graphics in Qt 4 for the Developer Road Show 2006. Only one stop left now: Hamburg, next week, which is rumored to be a fairly large event with over 70 people signed up. This has been a good experience all in all, the best part of course getting a great deal of face-to-face-with-customer time. And I have to say, more than anything else, our customers are waiting for QCanvas. So that’s what this blog is about.

Have you seen this robot?

Have you ever used QCanvas? It’s a set of classes for visualizing light-weight graphical shapes on a 2D canvas. With collision detection, view transformations (like zooming, rotation, etc.), and support for managing millions of items efficiently, this tool has been used to write everything from charting apps, CAD / vector drawing apps, games (typically board-, platform- or asteriods-like games), and image editors. The classic QCanvas app, however, is the flow chart / UML editor tool. Imagine an API for the editor widget, and you’re pretty close to what QCanvas is. It’s simply amazing to see what people are using QCanvas for. My most common responses to seeing a customer demo are:

“No way, that can’t possibly be based on QCanvas!? QCanvas doesn’t support that, does it!?”

QCanvas doesn’t support what our customers are using it for. Hehe ;-). At the same time, isn’t it amazing how much you can tweak Qt classes to do exactly what you want them to? I must salute Warwick Allison, who wrote the original canvas, for coming up with a design that provides for so many possibilities. πŸ˜€

QCanvas was phased out of Qt with Qt 4. The main reason for this was that we were sure to finish the successor, and provide that as a replacement in 4.0. Unfortunately, the impact of finishing the 4.0 release was so significant that we couldn’t make it. So the replacement project, GraphicsView, was postponed, and QCanvas became part of Qt 4’s Qt3Support library. Now, Qt 4.1 was released shortly after, addressing very many 4.0 issues, and adding the missing classes that we couldn’t finish for 4.0. Unfortunately, GraphicsView wasn’t ready yet.

With 4.2 (hopefully available in Q3/Q4 this year), GraphicsView is finally here. GraphicsView is QCanvas’ official successor. This project has taken into account all the applications that we have seen QCanvas being used for, removing most of the things that people had to hack in earlier, and making proper features instead. The heart of the new project is in its new features.

In this example, QGraphicsView is used to visualize thousands of shapes that all have arbitrary transformations, colors and transparency. Click the image to see a 1:1 screenshot.

Let’s do a little rundown of some new features for GraphicsView. Keep in mind that this is a snapshot of the current set of features, and it may change between now and the final release. Scroll to the end of this article to see how you can influence the final touches of GraphicsView before it’s released.

  • Full double-precision coordinate system. Including negative world coordinates.
  • Item interaction support through event propagation.
    • All items can receive key, mouse, focus, and accessibility events.
    • Mouse events use real coordinates.
    • Some features, like selection and moving, are provided by default.
  • Items can now be rotated, scaled, etc., individually.
  • Items can now have a parent, and a list of children. Item positions and transformations are propagated from parent to child.
  • Support for OpenGL.
    • You can render onto a QGLWidget by inserting a new QGLWidget into the view.
    • The items can either draw using QPainter, or using raw GL, with untransformed coordinates.
  • View transformations now keep the center aligned.
  • The chunks in QCanvas are no longer explicit. The scene is automatically indexed, using an axis aligned BSP tree.
  • Animation support. Out with static item velocity, here comes proper animation path support.
  • The text item has as powerful editing capabilities as QTextEdit. Seriously. πŸ˜‰
  • Collision detection has been greatly improved.
“What? Who wouldn’t want to edit text rotated 170 degrees and with a 40% skew?” Four views visualizing a scene with 4 million chips. You can navigate the scene in real-time, zoom in to read the text on each chip, or zoom out and see the big picture: a bunch of happy trolls chilling.

In general, one major message is that the API is now so pleasant to work with that everyone will want to use it!

Now if this features list changes, and it probably will, then please don’t sue anyone for it. πŸ˜‰ No, seriously, Qt 4.2 is still many months away, and we will adapt to the feedback from when the first snapshots are available. QGraphicsView will be available as soon as we start generating snapshots for 4.2. Around that time, we may also release a beta package. When that happens, everyone must run and grab a snapshot, and start writing GraphicsView applications ;-). And let us know what you think. Where? There are several channels available.

  • Post to qt-interest (http://lists.trolltech.com/) – include GraphicsView in the subject.
  • Customers, you can post suggestions through your regular support channels.

Now stay put, and wait for the first snapshots of 4.2 to appear. There’s a lot of excellent stuff coming up in this release.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Graphics Items, Graphics View, KDE, Labs, Qt


Nicolas says:

Hi Andreas,

Thank you very much for your demo in Paris, it was really amazing. GraphicsView seems to be 10 or 100 times better than QCanvas. I can’t wait to test it.
On a side note, I really enjoy the Qt Roadshow : it was a great chance to talk with Qt developpers (not only at Trolltech).

polux says:

Looks amazing, can’t wait to test it !

Paul Benjamin says:

I thought QCanvas was not included in the GPL version of QT. I haven’t looked at QT since KDE 2.0 or so.

When did QCanvas get included in the GPL version?

Brad Hards says:

Looks like a good candidate for the PDF rendering that we do in Poppler, replace direct calls.

liquidat says:

Loosk very nice – I really hope that some of these abilities is used in KDE 4!
What I would really appreciate would be a kind of live demo (some stream or video file) showing the effects live.
I also would like to see a small pack of ready prepared sources and with a little documentation which users/developers could download to get a first feeling for it and could have some early tests without installing a whole developing environment with libraries installed into the system, and so on. Think of a kind of “chroot”ed package where you just compile and execute mini applications to see what’s going on, and where you can easily extend it with documented examples to see how easy it is to make a text rotating, and so on… Hm, I hope you got what I meant.

Another note: while I tried to spread the word I realized that some people refer to this new class as QGraphicsView – which name is right?


PS: you should delete the category “uncategorized” since you added categories to this post πŸ˜‰

Jeff says:

Looks great. Our company heavily uses CanvasView currently. I’d love to
see a ‘best fit’ feature that scales/adjusts and fits the screen so that all
objects in the canvasview will fit in the viewport tightly. A kind of world-view.
We need that feature.

Andreas says:

liquidat: QGraphicsView, QGraphicsScene, QGraphicsItem – those are class names. The working title for the project is just “GraphicsView”.

Jeff: I’ll see what we can do, but isn’t that quite easy to do by scrolling the scroll bars and transforming the view by hand?

liquidat says:

Thanks for the answer, I corrected that. And, certainly, any comment or correction on my short article is welcome.

Ben Schleimer says:

The work looks amazing. But why not release QGraphicsView now as an alpha and get more immidiate feedback? Sounds like something everyone should be playing with….


Andreas says:

Its dependencies to Qt 4.2 are too deep; it doesn’t work with Qt 4.1. But once 4.2 snapshots are available, you’ll be able to try it. πŸ™‚

Seb says:

Hi Andreas,

I saw you in Paris last week: great demos !

I discovered the Qt4 Model/View archi during the roadshow, and then I asked myself about the class QGrapicView (just because of its name) : is this class using the Model/View architecture ?


Radim says:

The worst problem of QCanvas is that it is terribly
slow with a bit larger raster items if zoomed in a view.
Can we hope that this will be solved in QGraphicsView?


Andreas says:

Seb: Thank you! Everyone else: That’s a carrot for customers attending Trolltech events ;-). Yes, graphicsview is based on model/view, but it doesn’t use the abtract item model, passing an index to data(). It’s purely item based, like QCanvas is/was.

Radim: I think you’re talking about QPainter’s general performance with transformed drawing. That’s not GraphicsView / QCanvas related directly, but rather a question of QPainter and the paint engines’ speed. I guess we’ll see when GraphicsView is out what the performance differences are.

Tommy says:

I’m really looking forward to the new GraphicsView! I hope there will be an easy migration from existing QCanvas code to the new classes, we have a lot of QCanvas code. It the general structure is comparable it should not be too much of an impact.

A few things I would like to see in GraphicsView:

a) Allow to embed QWidgets into the view and handle them like items on the canvas. The current QCanvas does’t really support this.

b) Provide a mechanism for items to detect if they are obscured or not. Currently I display items that have their own events (i.e. a stock ticker), rendering the information is quite expensive. If an item is obscured by another top level window or even another item I have no way of knowing that and have to still go through all my expensive rendering only for it to not be displayed.


mhoover says:

Cool! Thanks for the carrot, Andreas.

A lesser question: how difficult / easy will it be to migrate a QCanvas-based application to QGraphicsView. Will it require easy find-and-replace changes or will it take some redesigning?

Andy Brice says:

Sounds great. I would like to see:

-the horrible text rotation problems in QCanvas Qt3 on Mac fixed – these have caused me big problems
-having a class for drawing SVG items in QGraphicsView would be useful
-a good example, e.g. an ultra simple CAD/drawing package
-it available as soon as possible!

I’m glad the ‘chunks’ are gone. In Qt3 it is far too easy to end up with chunks pointing to non-existent items.

Bring it on!!!

Andy Brice says:

I would like:

-the horrible text rotation problems in QCanvas Qt3 on Mac fixed – these have caused me big problems
-a class for drawing SVG items in QGraphicsView (not essential, but would be nice)
-a good example, e.g. an ultra simple CAD/drawing package
-it available as soon as possible!

I’m glad the ‘chunks’ are gone. In Qt3 it is far too easy to end up with chunks pointing to non-existent items.

Bring it on!!!

Andreas says:

The slow rendering of rastered graphics is gone, at least until one pixel covers the whole screen (at that point, suddenly things get horribly slow again, but I’m working on that).

As for embedding widgets, that will never be supported. QWidget is simply incompatible with the canvas design; for one thing, it’s not transformable. However, QGraphicsItem itself is now so powerful that you can write advanced controls yourself. One example is the pushbutton, which we’ve done in less than 100 lines (although only the essential features are supported).

We are planning on providing some of our controls as standard graphicsitems – one example being the text control. Other controls may appear later.

Whether an item is obscured or not – I’ll have to think about that. It’s quite hard for an item to know if it’s obscured. It may be overdrawn with an arbitrarily irregular shape, which may or not be filled with an opaque color. I’m thinking it’s easy to write something like that yourself, though.

benoit says:


I am quite surprised that GraphicView finally don’t use Interview. QT will end up having 3 different model/view systems: Interview, the QTextDocument which is sort of an MVC ‘thanks’ to some of its signals and QTextEdit/Browser, and finally GraphicView item system.

Some users (ok, well at least me:) have invested a lot of time exposing their datas to Interview, so it would probably be useful to have some sort of proxy classes to connect both frameworks together (Interview/Graphicview). Eventually Interview could be used at some ‘low’ level, and expose a more user friendly item interface at a higher level, allowing users to choose the system they want?

Because, reading this excellent list of new features, I feel that a lot of functionalities will be shared by the two interfaces: Item insertion, suppression, data change, selection and persistent “item” indexes have sense in both contexts. We could for example graphically display a file list model, reusing DisplayRole, DecorationRole, SizeHintRole and defining others.

Sorry for the long digression, but I am more than interested by the GraphicView release πŸ™‚

(Another interesting feature would be large image support, with pyramidal multi-res, as it is done in QGIS (with support for image clipping within the view BSP of course!))


Andreas says:

The short answer to the interview question is: How would you do it? We have tried several approaches, and they all end up being quite horrible. Interview is designed around a table model, where rows and columns decide an item’s location. Without this basic constraint, the only way to map items in a graphics scene to a table is as a single column, where each row represents an ID for an item. The item’s geometry has to be queried via the model; the row index is useless. Item selection can no longer use index ranges, and efficient item discovery relies on maintaining a separate index on top of the model – otherwise you have to iterate over all rows for any item discovery method. Parent-child relationships for items become horribly complex; they simply don’t map well to the table model. The delegate, which is owned by the view, and typically draws items radically differently depending on the view, needs to know the item’s geometry in order to draw. But since the model doesn’t know the delegate, it has to return the same geometry always. So the delegate provides no value anymore… It has to query the model for data about its own appearance, and if you think of it – the model needs to basically draw the item too.

On top of this – you could not use any of Qt’s models with a graphics view, and no graphics model would map to any of the existing views, delegates or selection models that Qt provides. The question is then, what does the framework give you?

In general, for GraphicsView, the Interview framework would just be in the way. If we are to provide an abstract model for GraphicsView at some point, and we very well may, then it will not be based on Interview.

I hope this answers your questions.

benoit says:

Thank your for your answer,

Well, Interview is a trade-off between a pure model that would encode relations and data separately, and a standard container (list, tree, and array). This is unfortunate for graphic views that don’t care much about columns, but the architecture to maintain coherency between the model and the view trough a sequence of complex hierarchical insertion/deletion/selection operations is still one of the best I have ever seen.

As I understand it, GraphicsItem, will probably propose some sort of item scene graph with the usual graphic operations being propagated across the hierarchical structure (Selection and dragging, z sorting, bounding box/polygon, matrix stack, spatial search, perhaps even more?).

In such a system, Interview could well encode the scene graph topology, and the visual part could be handled more or less separately in the view. For example, via a dedicated QObject transmitted with QModelIndex::internalPointer(), or a mapping system on the view side that would deal with loading resources such as stylesheets or geometry from external svg files or primitive objects.

In your Bender sample, one could easily imagine a tree view modelling the robot skeleton, and dedicated delegates to control local items matrixes. Without Interview, doing the mapping with such views (very common in industrial applications), and a dedicated GraphicsView item system is quite a lot of work (even more to update the two kind of view simultaneously).

Of course, such a system could perfectly be implemented on top of GraphicsView, but you will have to throw a lot of signals (with the very specific begin*()/end*() update mechanism needed by QAbstractModelItem that is often not available). Interview, despite its limitations is very good at doing just that in a way that is consistent with what already exists! It looks to me that such a work of mapping between application and graphic data it is at least 50% of the real work, especially if GraphicsView is as powerful than it looks like πŸ™‚

Of course, I would perfectly understand if such functionalities had been specified as being outside the scope of GraphicsView. It would however be nice to ensure that the item system has the signals and virtual methods needed for such a binding mechanism to be built without too much pain ! (For example, exactly _not_ as in the QTextDocument way”

Andreas says:

I guess you’re talking about MVC in general – yes, you can model a scene graph using MVC. But not with Interview – at least not efficiently. Applying Interview to GraphicsView would be pushing the camel too far through the head of the needle. I’m sure if you try to implement exactly what you’ve described, then you’d come to the same conclusion as in my last post.

If there’s a need to visualizing more than say – 4 000 000 items in a scene, then we might come up with an abstract graphics model.

Commenting closed.

Get started today with Qt Download now