Using kqmlgraphplugin in Plasma Next
Aaron J. Seigo
aseigo at kde.org
Tue Feb 4 13:51:50 GMT 2014
On Saturday, February 1, 2014 16:24:57 Sebastian Kügler wrote:
> > For a real hardware accelerates canvas you should open up Chrome and
> > go to this link: http://fhtr.org/gravityring/sprites.html I doubt that
> > would be possible with the same performance in the QML canvas ;)
> This is entirely unrelated. I could post a link to Halflife 2 and say that
> it's probably not possible with a canvas. It totally ignores the point,
> though: the usecase is completely different (is there a usecase for your
> example, anyway?), and a canvas seems to be the wrong tool for the job in
> this case as well. Does it have anything to do with graphs? I don't think
i think Mark’s point was that with a canvas that is hardware accelerated you
can do pretty impressive things with good performance. looking at the canvas
in QtQuick 2:
it has QtQuick 2 has two possible targets: Canvas.Image and
then there are three strategies: Immediate, Threaded and Cooperative.
Immediate means in the main GUI thread (not wanted here); Threaded starts a
thread just for that canvas; Cooperative uses the QML scene's render thread.
the Image target paints on to a QImage and the other uses an OpenGL buffer. in
both cases, QPainter is used, and the draw commands given are re-played onto
that paint device.
so with FramebufferObject + Cooperative (FBO+Threaded is not supported on all
platforms, in specific MS Windows) rendering would occur outside the main
thread ... and then it will all come down to how well optimized the QPainter
system is for operation on an OpenGL buffer in Qt5 (i honestly don’t know).
*if* it were to convert all operations to native OpenGL calls (or at least the
expensive ones), then things are likely to be fast like in the example Mark
posted. so if we look further into *that* we find that it uses a
QOpenGLPaintDevice to paint on a QOpenGLFramebufferObject. the fbo is not very
interesting, but the paint device is. here’s a bit from its documentation:
The QOpenGLPaintDevice is almost always hardware accelerated and
has the potential of being much faster than software
rasterization. However, it is more sensitive to state changes, and
therefore requires the drawing commands to be carefully ordered to
achieve optimal performance.
looking at the opengl paint engine most everything is indeed done using
openGL. so when the paint commands from the QtQuick canvas are replayed in the
render thread, if a FramebufferObject is used, it should benefit from hardware
how much in this case .. i don’t know. perhaps Bhushan can try setting the
target and strategy in his plotter and look for differences in performance?
Aaron J. Seigo
More information about the kde-core-devel