Qt 2D Drawing?
-
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 -
@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 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).@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).
-
@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).@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)
-
Use transformation i.e.:
QGraphicsItem item; item.setTransform( QTransform().scale( 1., 0.));should do the trick.
@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?
-
Also, how can I re-arrange the order of the
QGraphicsItemsin myQGraphicsScene? I couldn't find the answer to this question inQGraphicsScene's page, and it's quite important to me. Sorry for making this thread last forever.
