[Interest] Embedding QWindow
Till Oliver Knoll
till.oliver.knoll at gmail.com
Tue Aug 5 13:29:24 CEST 2014
Am 05.08.2014 um 10:48 schrieb Filip Piechocki <fpiechocki at gmail.com>:
> According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget
> never use the QWidget::createWindowContainer() :) use QQuickWidget instead.
Read the fine print: ;)
"having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget"
The reason is probably related to buffering: according to the blog all drawing of the QQuickWidget - that includes (raw) OpenGL drawing as well, I guess - will first go into an application specific buffer where it is combined with all the other widget paintings (notably "transparent overlays" etc., which otherwise would cause "rendering artifacts" when using "native windows").
That "per Qt application" buffering (especially referring to "raw OpenGL") even raises more interesting questions on platforms such as OS X where the Window (composition) Manager itself introduces yet another "per application buffer" (so "swapping GL double buffers" on OS X is in fact pointless, since the window manager will do this for you, too).
So you render "into the Qt application buffer", which gets copied into the "OS specific per application buffer", which eventually (with the whole composited desktop) is copied into the video ("front") buffer.
Even more interesting: "Retina displays" (on OS X). By default the OpenGL framebuffer resolution that is created by the OS when requesting a "window size of w times h points" is "half the resolution of the Retina display", such that the same amount of OpenGL "fragments" are processed by default, as compared to a non-Retina display with the same window size [in points].
If one really wants to draw with OpenGL in the "native (physical) resolution" then a flag (in Core Graphics?) can be set before creating the corresponding "OpenGL Cocoa widget".
Besides the Retina use case there is another "full screen with custom resolution" use case: instead of switching the graphic mode (resolution) for "full screen OpenGL" applications one simply requests a custom size of the frame buffer. The window manager itself will then scale up that buffer (without the application having to deal with that, apart from initially requesting the "custom size buffer") to the physical screen resolution.
I wonder how this all adds up when the application introduces yet another "per application composition layer with buffer"...?
But yes, there are issues with createWindowContainer ;) (especially on certain embedded systems with no Window Manager). But from what I understand they are not worse than what we know from QGLWidget (on desktop systems anyway).
And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering!
By now it should be clear that if you want to have "as few as possible between you and the GPU": use QWindow only!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest