Using kqmlgraphplugin in Plasma Next

[Aaron J. Seigo]

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
> so.

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 
Canvas.FramebufferObject. 

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:

===
Performance

    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 
acceleration.

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