Performance of QPainter?
-
Hi,
I was musing about the current (future) situation of
QPainter, and whether I should use it as the principal painting engine for a new graphics-intense project or use a third-party library for the painting (except for the widgets, of course).QPainteris fine and deeply anchorend in the classic widgets so it will stay with us for a while for sure. However, I am uncertain about its performance nowadays. I remember it's got an OpenGL backend a while back, though, but I can't tell if there is much development going on. Will it stay with OpenGL? Vulkan, eventually?
Generally I considerQPainterto be a mature and very comfortable tool, and I really like to work with it. Alas, there is not so much to choose from. Cairo seems a bit in need for active development, too, for instance, Blend2D is fast but AFAIK lacks most of the outstanding clipping features ofQPainter. Skia is very similar toQPainter.Your thoughts on this are very welcome.
Kind regards and Happy New Year,
Sven -
Hi and happy new year !
Did you already take a look at the Graphics topice in Qt's documentation ? It contains the current information about the tech stack used and what you can do with it. It might have some answers to the questions you have.
-
Hey SGaist,
thanks for the pointer. Yes, I dug through the documentation (IMHO, Qt API has one of the best and most concise documentation that I know), but that kind of raised my concern.
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
I'm not really sure if the traditional rendering stack has been touched for a while. Not that this is a bad thing by itself, it seems to run quite flawlessly.I'm just worried that it stays that way in the foreseeable future...
-
Hey SGaist,
thanks for the pointer. Yes, I dug through the documentation (IMHO, Qt API has one of the best and most concise documentation that I know), but that kind of raised my concern.
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
I'm not really sure if the traditional rendering stack has been touched for a while. Not that this is a bad thing by itself, it seems to run quite flawlessly.I'm just worried that it stays that way in the foreseeable future...
@Kamajii said in Performance of QPainter?:
I remember it's got an OpenGL backend a while back, though, but I can't tell if there is much development going on. Will it stay with OpenGL? Vulkan, eventually?
Do you mean: The ability to use QPainter in QOpenGLWidget?
Qt has mostly moved away from using a single graphics backend directly, towards using the Rendering Hardware Interface (RHI). A proof-of-concept has been made to port QPainter to the RHI, but it hasn't been polished yet (and it has been ~5 years unfortunately): https://bugreports.qt.io/browse/QTBUG-74407
@Kamajii said in Performance of QPainter?:
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
Qt Quick is currently the main thing that uses the Rendering Hardware Interface (RHI), but it's not the only thing.
- Qt 3D (now deprecated) uses the RHI too
- QRhiWidget lets you display (non-Qt Quick) RHI content in a QWidget
And this example shows how to use QPainter (+ QImage) to paint things into the RHI: https://doc.qt.io/qt-6/qtwidgets-rhi-cuberhiwidget-example.html
But to answer your main question about QPainter's performance: Since QPainter is currently designed for software rendering, it will likely be a bottleneck in a graphics-intensive project today. This could change if/when work on QTBUG-74407 is completed.
-
@Kamajii said in Performance of QPainter?:
I remember it's got an OpenGL backend a while back, though, but I can't tell if there is much development going on. Will it stay with OpenGL? Vulkan, eventually?
Do you mean: The ability to use QPainter in QOpenGLWidget?
Qt has mostly moved away from using a single graphics backend directly, towards using the Rendering Hardware Interface (RHI). A proof-of-concept has been made to port QPainter to the RHI, but it hasn't been polished yet (and it has been ~5 years unfortunately): https://bugreports.qt.io/browse/QTBUG-74407
@Kamajii said in Performance of QPainter?:
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
Qt Quick is currently the main thing that uses the Rendering Hardware Interface (RHI), but it's not the only thing.
- Qt 3D (now deprecated) uses the RHI too
- QRhiWidget lets you display (non-Qt Quick) RHI content in a QWidget
And this example shows how to use QPainter (+ QImage) to paint things into the RHI: https://doc.qt.io/qt-6/qtwidgets-rhi-cuberhiwidget-example.html
But to answer your main question about QPainter's performance: Since QPainter is currently designed for software rendering, it will likely be a bottleneck in a graphics-intensive project today. This could change if/when work on QTBUG-74407 is completed.
@JKSH said in Performance of QPainter?:
Do you mean: The ability to use QPainter in QOpenGLWidget?
I think so, AFAIK that's the intended way to make use of QPainter's accelerated painting through OpenGL.
Qt has mostly moved away from using a single graphics backend directly, towards using the Rendering Hardware Interface (RHI). A proof-of-concept has been made to port QPainter to the RHI, but it hasn't been polished yet (and it has been ~5 years unfortunately): https://bugreports.qt.io/browse/QTBUG-74407
And that's exactly what I'm musing about :-S It's working great I think, but it's just been sitting there eversince. So I suppose what eventually will/should happen is that QPainter also gets an RHI backend.
This could change if/when work on QTBUG-74407 is completed.
Like I said I don't think there are many equally-capable painters out there at the moment, unfortunately.
-
Hi,
I was musing about the current (future) situation of
QPainter, and whether I should use it as the principal painting engine for a new graphics-intense project or use a third-party library for the painting (except for the widgets, of course).QPainteris fine and deeply anchorend in the classic widgets so it will stay with us for a while for sure. However, I am uncertain about its performance nowadays. I remember it's got an OpenGL backend a while back, though, but I can't tell if there is much development going on. Will it stay with OpenGL? Vulkan, eventually?
Generally I considerQPainterto be a mature and very comfortable tool, and I really like to work with it. Alas, there is not so much to choose from. Cairo seems a bit in need for active development, too, for instance, Blend2D is fast but AFAIK lacks most of the outstanding clipping features ofQPainter. Skia is very similar toQPainter.Your thoughts on this are very welcome.
Kind regards and Happy New Year,
Sven@Kamajii said in Performance of QPainter?:
I was musing about the current (future) situation of QPainter , and whether I should use it as the principal painting engine for a new graphics-intense project
No
QPainter has terrible performance on some use cases (like multi-pixel width cosmetic pens)@Kamajii said in Performance of QPainter?:
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
That's right. QPainter is going to stay in a stable state, but don't expect any improvements.
@Kamajii said in Performance of QPainter?:
So I suppose what eventually will/should happen is that QPainter also gets an RHI backend.
I don't see that happening like, ever.
I have made the transition from QGraphicsView (which uses QPainter) to QtQuick a few years ago, and I haven't looked back. You can get really great performance by building a QML scene with custom-drawn, C++-written QQuickItems.
EDIT: I should add that the documentation for writing QQuickItems in C++ using SceneGraph is...lacking. There are a few blog posts by KDAB to help, if I remember correctly.
-
@Kamajii said in Performance of QPainter?:
I was musing about the current (future) situation of QPainter , and whether I should use it as the principal painting engine for a new graphics-intense project
No
QPainter has terrible performance on some use cases (like multi-pixel width cosmetic pens)@Kamajii said in Performance of QPainter?:
It all seems to revolve around QtQuick now, and QWidgets/QPainter seems to be a bit sidelined somehow.
That's right. QPainter is going to stay in a stable state, but don't expect any improvements.
@Kamajii said in Performance of QPainter?:
So I suppose what eventually will/should happen is that QPainter also gets an RHI backend.
I don't see that happening like, ever.
I have made the transition from QGraphicsView (which uses QPainter) to QtQuick a few years ago, and I haven't looked back. You can get really great performance by building a QML scene with custom-drawn, C++-written QQuickItems.
EDIT: I should add that the documentation for writing QQuickItems in C++ using SceneGraph is...lacking. There are a few blog posts by KDAB to help, if I remember correctly.
@Asperamanca How tricky was it to make the transition from QGraphicsView/QGraphicsScene/QGraphicsItem to QtQuick? I am currently trying to do it but my current implementation is so qpainter focused that i am not even sure i can make the switch. I tried to look at QQuickPaintedItem but I am not sure if it uses hardware acceleration or not. Would i have to use something like QQuickRhiItem?
-
@F_Mehmood Since they don't use the same concepts, it depends on your usage of the QGraphicsView framework.
There's no 1-to-1 porting guide, if you do lots of complex drawing with polygons or curves it will be tricky. If you are using basic shapes and controls it can be simple.QQuickPaintedItem is not hardware accelerated. QQuickRhiItem but more complex, you might not have to use it and could maybe just use existing Items.
Do you have a screenshot of your application (or a similar one)? A drawing/description would also do.
