<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div style="-webkit-text-size-adjust: auto; ">Am 05.08.2014 um 10:48 schrieb Filip Piechocki <<a href="mailto:fpiechocki@gmail.com">fpiechocki@gmail.com</a>>:</div><div style="-webkit-text-size-adjust: auto; "><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto; "><div><div dir="ltr">According to this blog post: <a href="http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget">http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget</a> <div>never use the QWidget::createWindowContainer() :) use QQuickWidget instead.</div></div></div></blockquote><br><div style="-webkit-text-size-adjust: auto; ">Read the fine print: ;)</div><div style="-webkit-text-size-adjust: auto; "><br></div><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">"having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget"</span></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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").</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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).</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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.</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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].</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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".</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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.</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">I wonder how this all adds up when the application introduces yet another "per application composition layer with buffer"...?</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">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).</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering!</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">By now it should be clear that if you want to have "as few as possible between you and the GPU": use QWindow only!</div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; "><br></div><div style="-webkit-text-size-adjust: auto; ">Cheers,</div><div style="-webkit-text-size-adjust: auto; ">  Oliver</div></body></html>