Qt 2D Drawing?

timday

I see a lot of complicated sounding stuff being talked about here.

To what extent can QML/QSG meet your needs? OpenGL-powered QSG provides all the rendering power you need; if a pure QML-approach ran out of steam for you, I suspect it'd be because the javascript for whatever sprite behaviour is needed becomes too complex and slow, not the rendering. But more complicated behaviour could be moved into C++ without leaving QML & QSG behind, using the usual QML-C++ interop (properties, invokables etc).

Complete qmlscene runnable example below (placeholder icons courtesy of lorempixel):

import QtQuick 2.2

// Silly QML sprites demo; 200 randomly positioned/moving sprites
// Sprites toggle color when clicked

Rectangle {
  id: main
  width: 1024
  height: 768
  color: 'black'

  Timer {
    id: ticker
    interval: 1000.0/60.0
    running: true
    repeat: true
  }

  Repeater {

    // Number of sprites
    // Can go up to 1000 happily enough on an old Core2Duo lappy (Intel graphics)
    // More modern HW probably much more.
    model: 200

    Item {
      id: sprite

      x: ox-0.5*width
      y: oy-0.5*width
      width: 64
      height: 64
      rotation: Math.random()*360.0

      property real ox: main.width*Math.random()
      property real oy: main.height*Math.random()
      property real vx: -1.0+2.0*Math.random()
      property real vy: -1.0+2.0*Math.random()
      property real vr: -1.0+2.0*Math.random()

      Image {
        anchors.fill: parent
        opacity: 0.75
        source: 'http://www.lorempixum.com/64/64/cats/'+((1+index%10).toString())
        smooth: true
      }

      Rectangle {
        id: highlight
        anchors.fill: parent
        visible: opacity!=0.0
        opacity: 0.0
        color: 'red'
        Behavior on opacity {NumberAnimation {duration: 500}}
      }

      MouseArea {
        anchors.fill: parent   
        onClicked: highlight.opacity=1.0-highlight.opacity
      }

      Connections {
        target: ticker
        onTriggered: {
          ox+=vx
          if (ox<0.0) {ox=0.0;vx=-vx;} else if (ox>main.width) {ox=main.width;vx=-vx;}
          oy+=vy
          if (oy<0.0) {oy=0.0;vy=-vy;} else if (oy>main.height) {oy=main.height;vy=-vy;}
          rotation+=vr
        }
      }
    }
  }
}

JKSH

@Pippin said:

Are you sure, because if you browse QGraphicsScene's page, CTRL+F "QPixmap" doesn't have that many results, also CTRL+F "rotat" has no results :S

Yes, I'm sure.

You don't rotate the QGraphicsScene itself. Instead, you rotate the individual items.

Basically, if you have an std::vector of 10 QPixmaps, an std::vector of 10 angles, an std::vector of 10 horizontal scales, and an std::vector of 10 positions, how would you draw these 10 QPixmaps on the QGraphicsScene, according to the other std::vectors I listed?

Wrap each QPixmap inside a QGraphicsPixmapItem (this is a subclass of QGraphicsItem)
Add your QGraphicsPixmapItems to your QGraphicsScene
Rotate your items using QGraphicsItem::rotate()
Move your items using QGraphicsItem::setPos()
Show your QGraphicsScene using a QGraphicsView

EDIT: Note that there are many ways to do what you want in Qt. @LuGRU showed you 3, and @timday showed you another. The QGraphicsScene option requires the least amount of coding, but might not offer the best performance. I suggest you try it first, to familiarize yourself with Qt. If its performance is not satisfactory, then try the other options. Good luck.

LuGRU

To sum up my post I will share info about performance of Graphics Framework in Qt on project that I'm involved with.
Running 25 video items - custom libVlc base QGraphicsItems - that plays videos of 624x352 at 23.976fp hits 50% CPU on i7-4770 in debug mode, all items playback is smooth.
For around 230 items, around 1/5 is text with high aliasing rest is, pixmaps, QGraphicsPathItem - panning and zooming view when all those objects are visible - all objects do have transparency - is not smooth, I would say 15fps, going to OGL - smooth.

So drawing 200 sprites shouldn't be a big of a problem.

Maximizing performance:
QtQuick 1 - deprecated - used OGL direct mode - each time frame was repainted scene was uploaded to GPU
QtQuick 2 - currently used - uses VBO / IBO - vertex / image buffer object's - sending to GPU new data only when data do change - decrease bandwidth usage increase performance.
QGraphicsView + QGLWidget - I'm not sure but suspecting direct OGL mode, this of course can be customized to use VBO / IBO for item data

Pippin

@timday Thank you for your reply but I'm afraid I don't know most of the things you're talking about (QML, QSG...) :S I also don't know in what language the code you wrote is :S

@JKSH Thank you for your reply, the point is, I'm going to completely transform my SMFL project into a Qt project (because I can't make Qt and SFML efficiently work together). This is going to take weeks, if not months, so I'd rather not try out each method then choose which one is best. I'm gathering all the information I can find to choose now. Basically, my project draws (rotable, scalable) QPixmaps onto a window, as well as (movable) QPushButtons. These are the two main things it has to draw at each frame. There are other things, like colored circles, rectangles or numbers, but that shouldn't be a problem I think.

You said that QGraphicsScene stuff may not offer the best performance, but you also said that it was coded for these things. So, what do you think could offer nice performance?

@LuGRU Thank you for your reply, I'm not at all familiar with QtQuick though. I'm not familiar with VBO/IBO either. Actually, I don't even use Qt Creator when I'm coding Qt things. I'm using Ubuntu and am compiling everything through the terminal (qmake, make, ./run).

timday

@Pippin The language is QML which supposedly stands for Qt Modelling Language or Qt Meta Language. It's part of the QtQuick part of Qt. Basically, instead of writing acres of C++ widget plumbing code, it lets you express UI declaratively with an elegant domain specific language (and the odd bit of javascript where imperative style is needed) and then the only bit of C++ you need is something to create a QQuickView to interpret the QML (and for convenience, the Qt SDKs provide a qmlscene tool which does exactly this). You're missing out on an (increasingly) important - and one of the best - parts of Qt if you're not familiar with QtQuick, IMHO. What sets QtQuick apart from other rapid application development tools is the ease of integration of C++ components into the QML (enabled by the moc-generated metadata) when some heavy lifting is needed (whether specialized OpenGL rendering, or intensive compute which would be too slow in javascript and really needs native code's power).

JKSH

@Pippin said:

I'm going to completely transform my SMFL project into a Qt project (because I can't make Qt and SFML efficiently work together). This is going to take weeks, if not months, so I'd rather not try out each method then choose which one is best. I'm gathering all the information I can find to choose now.

Before you port any large project from one framework to another, it's always wise to spend a few days trying out your target framework. This applies to all frameworks, not just Qt.

Follow some tutorials; write a dummy program that animates 200 sprites, using similar sizes and frame rates as your final program. Does it perform well enough? If not, go try a different framework. But if your dummy program performs well enough, make it animate 400 sprites -- if it still works well, then you're fully confident it can handle your final program.

When trying to work out what's "best", you also need to consider the effort required to use the technology vs. the benefits you gain.

Basically, my project draws (rotable, scalable) QPixmaps onto a window, as well as (movable) QPushButtons. These are the two main things it has to draw at each frame. There are other things, like colored circles, rectangles or numbers, but that shouldn't be a problem I think.

What frame rate do you want? Any special effects? How does your user interact with these objects?

Note: In the Graphics View Framework or QML/Qt Quick, you don't need to manually manage each frame. Just place your items, tell them how to move, and Qt will take care of the frames for you.

You said that QGraphicsScene stuff may not offer the best performance, but you also said that it was coded for these things. So, what do you think could offer nice performance?

Yes, the Graphics View Framework was designed for handling lots of 2D sprites. The API is very easy to use, and allows you to do animations, scaling, rotations. In contrast, QPainter was not designed for animating sprites (even though it can do so, if you're persistent). Your code will become a nightmare to maintain; don't use QPainter for your project.

The Graphics View Framework performs best when your sprites are made of lines, polygons, arcs, texts, etc. Using custom images/pixmaps will incur an overhead. How much overhead? I don't know, I've never measured. It also really depends on how big your sprites are and what you want them to do -- I'm just giving you the insight you need to measure it yourself. (Alternatively, hire a consultant)

QML/Qt Quick was designed for creating fluid, modern, mobile-phone-style GUIs. It's a much newer technology than Graphics View, so it performs better in some cases, thanks to GPU acceleration. Does it perform better for your project? I don't know, I've never measured. Again, it's up to you to measure it if you want to know.

The bottom line is: the Graphics View Framework is definitely easier to use, but QML/Qt Quick might perform better (no guarantees), and it requires you to learn a new language. If it were my project, I'd do a quick test on the Graphics View Framework first. If that's not good enough, try QML/Qt Quick. If that's still not good enough, use raw OpenGL. (I'm reasonably confident that Graphics View meets your requirements though)

Pippin

Okay thanks everyone! I'll give the Graphics View Framework a try then. About scaling though, may I ask how one can scale an item horizontally or vertically (not both) ? QGraphicsItem::setScale() seems to scale both dimensions.

LuGRU

Use transformation i.e.:

            QGraphicsItem item;
            item.setTransform( QTransform().scale( 1., 0.));

should do the trick.

Pippin

@LuGRU Thanks for the tip.

Now, about OpenGL acceleration:

To enable OpenGL support, you can set a QGLWidget as the viewport by calling QGraphicsView::setViewport().

Source: http://doc.qt.io/qt-5/graphicsview.html

I'm not sure I understand this correctly. To trigger OpenGL acceleration, I would only have to do something like that?

QGLWidget foo;
MyQGraphicsView.setViewport(&foo);

Or is it more complicated than this?

Pippin

Also, how can I re-arrange the order of the QGraphicsItems in my QGraphicsScene? I couldn't find the answer to this question in QGraphicsScene's page, and it's quite important to me. Sorry for making this thread last forever.

mrjj

@Pippin
Hi
you mean zorder ?
setZValue, isObscured and isObscuredBy
And as side note.
Did you check out the 40000 sample ?

LuGRU

@Pippin
OGL - Yes, just make sure QGlWidget don't go out of the scope.
You can also fiddle with ogl format settings, write You own shaders - i.e. as part of pain() in QGraphicsItem etc.