qt5base-lts/tests/manual/qopenglwidget/openglwidget/openglwidget.cpp

177 lines
4.0 KiB
C++
Raw Normal View History

// Copyright (C) 2016 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
#define GL_GLEXT_PROTOTYPES
#include "openglwidget.h"
#include <QtWidgets/private/qwidget_p.h>
#include <QOpenGLFramebufferObject>
#include <QWindow>
#include <qpa/qplatformwindow.h>
#include <QDebug>
#include <QTimer>
#include <QtGui/QOpenGLFunctions>
#include <QtGui/QGuiApplication>
#include <QtGui/QMatrix4x4>
Compose render-to-texture widgets through QRhi QPlatformTextureList holds a QRhiTexture instead of GLuint. A QPlatformBackingStore now optionally can own a QRhi and a QRhiSwapChain for the associated window. Non-GL rendering must use this QRhi everywhere, whereas GL (QOpenGLWidget) can choose to still rely on resource sharing between contexts. A widget tells that it wants QRhi and the desired configuration in a new virtual function in QWidgetPrivate returning a QPlatformBackingStoreRhiConfig. This is evaluated (among a top-level's all children) upon create() before creating the repaint manager and the QWidgetWindow. In QOpenGLWidget what do request is obvious: it will request an OpenGL-based QRhi. QQuickWidget (or a potential future QRhiWidget) will be more interesting: it needs to honor the standard Qt Quick env.vars. and QQuickWindow APIs (or, in whatever way the user configured the QRhiWidget), and so will set up the config struct accordingly. In addition, the rhiconfig and surface type is (re)evaluated when (re)parenting a widget to a new tlw. If needed, this will now trigger a destroy - create on the tlw. This should be be safe to do in setParent. When multiple child widgets report an enabled rhiconfig, the first one (the first child encountered) wins. So e.g. attempting to have a QOpenGLWidget and a Vulkan-based QQuickWidget in the same top-level window will fail one of the widgets (it likely won't render). RasterGLSurface is no longer used by widgets. Rather, the appropriate surface type is chosen. The rhi support in the backingstore is usable without widgets as well. To make rhiFlush() functional, one needs to call setRhiConfig() after creating the QBackingStore. (like QWidget does to top-level windows) Most of the QT_NO_OPENGL ifdefs are eliminated all over the place. Everything with QRhi is unconditional code at compile time, except the actual initialization. Having to plumb the widget tlw's shareContext (or, now, the QRhi) through QWindowPrivate is no longer needed. The old approach does not scale: to implement composeAndFlush (now rhiFlush) we need more than just a QRhi object, and this way we no longer pollute everything starting from the widget level (QWidget's topextra -> QWidgetWindow -> QWindowPrivate) just to send data around. The BackingStoreOpenGLSupport interface and the QtGui - QtOpenGL split is all gone. Instead, there is a QBackingStoreDefaultCompositor in QtGui which is what the default implementations of composeAndFlush and toTexture call. (overriding composeAndFlush and co. f.ex. in eglfs should continue working mostly as-is, apart from adapting to the texture list changes and getting the native OpenGL texture id out of the QRhiTexture) As QQuickWidget is way too complicated to just port as-is, an rhi manual test (rhiwidget) is introduced as a first step, in ordewr to exercise a simple, custom render-to-texture widget that does something using a (not necessarily OpenGL-backed) QRhi and acts as fully functional QWidget (modeled after QOpenGLWidget). This can also form the foundation of a potential future QRhiWidget. It is also possible to force the QRhi-based flushing always, regardless of the presence of render-to-texture widgets. To exercise this, set the env.var. QT_WIDGETS_RHI=1. This picks a platform-specific default, and can be overridden with QT_WIDGETS_RHI_BACKEND. (in sync with Qt Quick) This can eventually be extended to query the platform plugin as well to check if the platform plugin prefers to always do flushes with a 3D API. QOpenGLWidget should work like before from the user's perspective, while internally it has to do some things differently to play nice and prevent regressions with the new rendering architecture. To exercise this better, the qopenglwidget example gets a new tab-based view (that could perhaps replace the example's main window later on?). The openglwidget manual test is made compatible with Qt 6, and gets a counterpart in form of the dockedopenglwidget manual test, which is a modified version of the cube example that features dock widgets. This is relevant in particular because render-to-texture widgets within a QDockWidget has its own specific quirks, with logic taking this into account, hence testing is essential. For existing applications there are two important consequences with this patch in place: - Once the rhi-based composition is enabled, it stays active for the lifetime of the top-level window. - Dynamically creating and parenting the first render-to-texture widget to an already created tlw will destroy and recreate the tlw (and the underlying window). The visible effects of this depend on the platform. (e.g. the window may disappear and reappear on some, whereas with other windowing systems it is not noticeable at all - this is not really different from similar situtions with reparenting or when moving windows between screens, so should be acceptable in practice) - On iOS raster windows are flushed with Metal (and rhi) from now on (previously this was through OpenGL by making flush() call composeAndFlush(). Change-Id: Id05bd0f7a26fa845f8b7ad8eedda3b0e78ab7a4e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-10-25 13:21:31 +00:00
#include <QOpenGLShaderProgram>
#include <QtGui/QScreen>
#include <QtCore/qmath.h>
#include <qopengl.h>
class OpenGLWidgetPrivate : protected QOpenGLFunctions
{
public:
OpenGLWidgetPrivate(QWidget *q)
: m_program(0), m_frame(0), q(q)
{
}
void initialize();
void render();
int width() {return w;}
int height() {return h;}
GLuint m_posAttr;
GLuint m_colAttr;
GLuint m_matrixUniform;
QOpenGLShaderProgram *m_program;
int m_frame;
int w,h;
QWidget *q;
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
int m_interval;
QVector3D m_rotAxis;
float clearColor[3];
};
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
OpenGLWidget::OpenGLWidget(int interval, const QVector3D &rotAxis, QWidget *parent)
: QOpenGLWidget(parent)
{
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
d.reset(new OpenGLWidgetPrivate(this));
d->clearColor[0] = d->clearColor[1] = d->clearColor[2] = 0.0f;
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
d->m_interval = interval;
d->m_rotAxis = rotAxis;
if (interval > 0) {
QTimer *timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(update()));
timer->start(interval);
}
}
OpenGLWidget::~OpenGLWidget()
{
}
void OpenGLWidget::initializeGL()
{
// qDebug("*initializeGL*");
d->initialize();
}
void OpenGLWidget::resizeGL(int w, int h)
{
// qDebug("*resizeGL*");
d->w = w;
d->h = h;
}
void OpenGLWidget::paintGL()
{
// qDebug("*paintGL* %d", d->m_frame);
d->render();
}
static const char *vertexShaderSource =
"attribute highp vec4 posAttr;\n"
"attribute lowp vec4 colAttr;\n"
"varying lowp vec4 col;\n"
"uniform highp mat4 matrix;\n"
"void main() {\n"
" col = colAttr;\n"
" gl_Position = matrix * posAttr;\n"
"}\n";
static const char *fragmentShaderSource =
"varying lowp vec4 col;\n"
"void main() {\n"
" gl_FragColor = col;\n"
"}\n";
void OpenGLWidgetPrivate::initialize()
{
initializeOpenGLFunctions();
m_program = new QOpenGLShaderProgram;
m_program->addShaderFromSourceCode(QOpenGLShader::Vertex, vertexShaderSource);
m_program->addShaderFromSourceCode(QOpenGLShader::Fragment, fragmentShaderSource);
m_program->link();
m_posAttr = m_program->attributeLocation("posAttr");
m_colAttr = m_program->attributeLocation("colAttr");
m_matrixUniform = m_program->uniformLocation("matrix");
}
void OpenGLWidgetPrivate::render()
{
const qreal retinaScale = q->devicePixelRatio();
glViewport(0, 0, width() * retinaScale, height() * retinaScale);
glClearColor(clearColor[0], clearColor[1], clearColor[2], 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
m_program->bind();
QMatrix4x4 matrix;
matrix.perspective(60.0f, 4.0f/3.0f, 0.1f, 100.0f);
matrix.translate(0, 0, -2);
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
const qreal angle = 100.0f * m_frame / 30;
matrix.rotate(angle, m_rotAxis);
m_program->setUniformValue(m_matrixUniform, matrix);
GLfloat vertices[] = {
0.0f, 0.707f,
-0.5f, -0.5f,
0.5f, -0.5f
};
GLfloat colors[] = {
1.0f, 0.0f, 0.0f,
0.0f, 1.0f, 0.0f,
0.0f, 0.0f, 1.0f
};
glVertexAttribPointer(m_posAttr, 2, GL_FLOAT, GL_FALSE, 0, vertices);
glVertexAttribPointer(m_colAttr, 3, GL_FLOAT, GL_FALSE, 0, colors);
glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);
glDrawArrays(GL_TRIANGLES, 0, 3);
glDisableVertexAttribArray(1);
glDisableVertexAttribArray(0);
m_program->release();
++m_frame;
Support mixing native child widgets with texture-based ones Currently QOpenGLWidget and QQuickWidget do not support having native child widgets inside the same top-level window. In some cases this is inevitable, f.ex. multimedia may require native windows when used from widget apps. winId() calls made for various (valid or invalid) reasons are also problematic. There are no blockers for supporting this setup, however. By storing multiple texture lists (one for each subtree where the root is a native widget), adding the missing markDirtyOnScreen calls, letting each native widget access the correct texture list (i.e. the one corresponding to its children) when they are (separately) flushed, and fixing composeAndFlush() to take the update region and the (native child) offset into account, it can all be made functional. The change also fixes the issue of keeping GL-based compositing enabled even after all render-to-texture widgets in the window become hidden. Due to the changes of how such widgets are gathered, composeAndFlush() is not invoked anymore when no such widgets are discovered for a given native parent. This is great since having compositing enabled infinitely is an issue for applications like Qt Creator that implement certain views with QQuickWidgets but cannot afford the cost of texture uploads in other places (e.g. for the text editor) on slower machines. The openglwidget manual test is greatly enhanced to test various situations (MDI, scroll areas, tab widgets, QOpenGLWidget as native child, QOpenGLWidget with non-tlw native parent, etc.) Task-number: QTBUG-48130 Task-number: QTBUG-49172 Change-Id: Iad098359c8bcf749f01c050da0853415e1550eda Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-11-03 10:41:01 +00:00
if (m_interval <= 0)
q->update();
}
void OpenGLWidget::setClearColor(const float *c)
{
d->clearColor[0] = c[0];
d->clearColor[1] = c[1];
d->clearColor[2] = c[2];
}