[Interest] Embedding QWindow

[Filip Piechocki]

On Tue, Aug 5, 2014 at 1:29 PM, Till Oliver Knoll <
till.oliver.knoll at gmail.com> wrote:

> 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: ;)
>

That's why I pasted the link to this article - so anybody can read it in
details :)


>
> "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!
>
>
>
> Cheers,
>   Oliver
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140805/4944c31f/attachment.html>