AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4bfe6ea251
qt5base-lts/tests/manual/qopengltextureblitter/qopengltextureblitwindow.cpp

154 lines
6.6 KiB
C++
Raw Normal View History

Use SPDX license identifiers Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-10 10:06:48 +00:00
// Copyright (C) 2016 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
#include "qopengltextureblitwindow.h"
#include <QtGui/QPainter>
Post-merge fixes Change-Id: I6acd29103f6cc550544e7422328d97ea0e2dcafb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-01-27 12:25:34 +00:00
#include <QtOpenGL/QOpenGLTexture>
Fix compilation of manual Open GL tests with Dynamic GL. Change-Id: Iffd57f26dfc9d6a00cab855270207fc4da7eb1ab Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
2015-01-15 13:02:57 +00:00
#include <QtGui/QOpenGLFunctions>
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
#include <QtGui/QMatrix4x4>
#include <QtCore/QCoreApplication>
#include <QtCore/QDebug>
QOpenGLTextureBlitWindow::QOpenGLTextureBlitWindow()
: QWindow()
, m_context(new QOpenGLContext(this))
{
resize(500,500);
setSurfaceType(OpenGLSurface);
QSurfaceFormat surfaceFormat = format();
if (QCoreApplication::arguments().contains(QStringLiteral("-coreprofile"))) {
surfaceFormat.setVersion(3,2);
surfaceFormat.setProfile(QSurfaceFormat::CoreProfile);
}
setFormat(surfaceFormat);
create();
m_context->setFormat(surfaceFormat);
m_context->create();
m_context->makeCurrent(this);
m_blitter.create();
Add support for TEXTURE_EXTERNAL_OES in the internal texture blitter Assuming that the target is always GL_TEXTURE_2D is not going to be sufficient when working with EGLStreams for example where GL_TEXTURE_EXTERNAL_OES is a must. The blitter is now changed to support multiple programs so other targets can easily be added as well in the future, if necessary. Change-Id: I247d30600222fb5af6305ed5d9740baa5e43e83e Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
2015-10-20 10:19:11 +00:00
qDebug("GL_TEXTURE_EXTERNAL_OES support: %d", m_blitter.supportsExternalOESTarget());
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
}
void QOpenGLTextureBlitWindow::render()
{
m_context->makeCurrent(this);
QRect viewport(0,0,dWidth(),dHeight());
Fix compilation of manual Open GL tests with Dynamic GL. Change-Id: Iffd57f26dfc9d6a00cab855270207fc4da7eb1ab Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
2015-01-15 13:02:57 +00:00
QOpenGLFunctions *functions = m_context->functions();
functions->glViewport(0,0,dWidth(), dHeight());
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
Fix compilation of manual Open GL tests with Dynamic GL. Change-Id: Iffd57f26dfc9d6a00cab855270207fc4da7eb1ab Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
2015-01-15 13:02:57 +00:00
functions->glClearColor(0.f, .6f, .0f, 0.f);
functions->glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
QOpenGLTexture texture(m_image);
QOpenGLTextureBlitter: fix source rect when origin is top left This fixes the issue that the blitter required sometimes the texture wrapping to be repeat Change-Id: I86150d008422facf9040873b0983b0e44be9ad24 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 20:59:56 +00:00
texture.setWrapMode(QOpenGLTexture::ClampToEdge);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
texture.create();
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
QOpenGLTexture texture_mirrored(m_image_mirrord);
texture_mirrored.setWrapMode(QOpenGLTexture::ClampToEdge);
texture_mirrored.create();
QRectF topLeftOriginTopLeft(QPointF(0,0), QPointF(dWidth()/2.0, dHeight()/2.0));
QRectF topRightOriginTopLeft(QPointF(dWidth()/2.0,0), QPointF(dWidth(), dHeight()/2.0));
QRectF bottomLeftOriginTopLeft(QPointF(0, dHeight()/2.0), QPointF(dWidth() /2.0, dHeight()));
QRectF bottomRightOriginTopLeft(QPoint(dWidth()/2.0, dHeight()/2.0), QPointF(dWidth(), dHeight()));
QRectF topLeftOriginBottomLeft = bottomLeftOriginTopLeft; Q_UNUSED(topLeftOriginBottomLeft);
QRectF topRightOriginBottomLeft = bottomRightOriginTopLeft; Q_UNUSED(topRightOriginBottomLeft);
QRectF bottomLeftOriginBottomLeft = topLeftOriginTopLeft;
QRectF bottomRightOriginBottomLeft = topRightOriginTopLeft;
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
QOpenGLTextureBlitter::Origin topLeftOrigin = QOpenGLTextureBlitter::OriginTopLeft;
QOpenGLTextureBlitter::Origin bottomLeftOrigin = QOpenGLTextureBlitter::OriginBottomLeft;
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
QMatrix4x4 topRightOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(topRightOriginTopLeft, viewport);
QMatrix4x4 bottomLeftOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(bottomLeftOriginTopLeft, viewport);
QMatrix4x4 bottomRightOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(bottomRightOriginTopLeft, viewport);
QMatrix3x3 texTopLeftOriginTopLeft = QOpenGLTextureBlitter::sourceTransform(topLeftOriginTopLeft, m_image.size(), topLeftOrigin);
QMatrix3x3 texTopRightOriginBottomLeft = QOpenGLTextureBlitter::sourceTransform(topRightOriginBottomLeft, m_image.size(), bottomLeftOrigin);
QMatrix3x3 texBottomLeftOriginBottomLeft = QOpenGLTextureBlitter::sourceTransform(bottomLeftOriginBottomLeft, m_image.size(), bottomLeftOrigin);
QMatrix3x3 texBottomRightOriginBottomLeft = QOpenGLTextureBlitter::sourceTransform(bottomRightOriginBottomLeft, m_image.size(), bottomLeftOrigin);
QSizeF subSize(topLeftOriginTopLeft.width()/2, topLeftOriginTopLeft.height()/2);
QRectF subTopLeftOriginTopLeft(topLeftOriginTopLeft.topLeft(), subSize);
QRectF subTopRightOriginTopLeft(QPointF(topLeftOriginTopLeft.topLeft().x() + topLeftOriginTopLeft.width() / 2,
topLeftOriginTopLeft.topLeft().y()), subSize);
QRectF subBottomLeftOriginTopLeft(QPointF(topLeftOriginTopLeft.topLeft().x(),
topLeftOriginTopLeft.topLeft().y() + topLeftOriginTopLeft.height() / 2), subSize);
QRectF subBottomRightOriginTopLeft(QPointF(topLeftOriginTopLeft.topLeft().x() + topLeftOriginTopLeft.width() / 2,
topLeftOriginTopLeft.topLeft().y() + topLeftOriginTopLeft.height() / 2), subSize);
QMatrix4x4 subTopLeftOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(subTopLeftOriginTopLeft, viewport);
QMatrix4x4 subTopRightOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(subTopRightOriginTopLeft, viewport);
QMatrix4x4 subBottomLeftOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(subBottomLeftOriginTopLeft, viewport);
QMatrix4x4 subBottomRightOriginTopLeftVertex = QOpenGLTextureBlitter::targetTransform(subBottomRightOriginTopLeft, viewport);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
m_blitter.bind();
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
m_blitter.blit(texture_mirrored.textureId(), subTopLeftOriginTopLeftVertex, texBottomRightOriginBottomLeft);
m_blitter.blit(texture_mirrored.textureId(), subTopRightOriginTopLeftVertex, texBottomLeftOriginBottomLeft);
m_blitter.blit(texture.textureId(), subBottomLeftOriginTopLeftVertex, texTopRightOriginBottomLeft);
m_blitter.blit(texture.textureId(), subBottomRightOriginTopLeftVertex, texTopLeftOriginTopLeft);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
m_blitter.blit(texture.textureId(), topRightOriginTopLeftVertex, topLeftOrigin);
m_blitter.blit(texture_mirrored.textureId(), bottomLeftOriginTopLeftVertex, topLeftOrigin);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
Make QOpenGLTextureBlitter public Change QOpenGLTextureBlitter to be a public API, as it was originally intended. There are now significant external uses outside qtbase (C++ compositor examples in QtWayland), and the API is considered proven enough. [ChangeLog][QtGui] QOpenGLTextureBlitter, a utility class to draw textured quads, has been made public. Change-Id: If7a2c94e1494195e2aa375d214932fa7b4c78321 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
2016-07-28 10:20:23 +00:00
m_blitter.setRedBlueSwizzle(true);
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
m_blitter.blit(texture.textureId(), bottomRightOriginTopLeftVertex, texTopLeftOriginTopLeft);
Make QOpenGLTextureBlitter public Change QOpenGLTextureBlitter to be a public API, as it was originally intended. There are now significant external uses outside qtbase (C++ compositor examples in QtWayland), and the API is considered proven enough. [ChangeLog][QtGui] QOpenGLTextureBlitter, a utility class to draw textured quads, has been made public. Change-Id: If7a2c94e1494195e2aa375d214932fa7b4c78321 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
2016-07-28 10:20:23 +00:00
m_blitter.setRedBlueSwizzle(false);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
m_blitter.release();
Add support for TEXTURE_EXTERNAL_OES in the internal texture blitter Assuming that the target is always GL_TEXTURE_2D is not going to be sufficient when working with EGLStreams for example where GL_TEXTURE_EXTERNAL_OES is a must. The blitter is now changed to support multiple programs so other targets can easily be added as well in the future, if necessary. Change-Id: I247d30600222fb5af6305ed5d9740baa5e43e83e Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
2015-10-20 10:19:11 +00:00
if (m_blitter.supportsExternalOESTarget()) {
// Cannot do much testing here, just verify that bind and release work, meaning that the program is present.
m_blitter.bind(0x8D65);
m_blitter.release();
}
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
m_context->swapBuffers(this);
}
void QOpenGLTextureBlitWindow::exposeEvent(QExposeEvent *event)
{
Q_UNUSED(event);
render();
}
void QOpenGLTextureBlitWindow::resizeEvent(QResizeEvent *event)
{
Q_UNUSED(event);
m_image = QImage(size() * devicePixelRatio(), QImage::Format_ARGB32_Premultiplied);
m_image.fill(Qt::gray);
QPainter p(&m_image);
QPen pen(Qt::red);
pen.setWidth(5);
p.setPen(pen);
QFont font = p.font();
font.setPixelSize(qMin(m_image.height(), m_image.width()) / 20);
p.setFont(font);
int dx = dWidth() / 5;
int dy = dHeight() / 5;
for (int y = 0; y < 5; y++) {
for (int x = 0; x < 5; x++) {
QRect textRect(x * dx, y*dy, dx,dy);
QString text = QString("[%1,%2]").arg(x).arg(y);
p.drawText(textRect,text);
}
}
p.drawRect(QRectF(2.5,2.5,dWidth() - 5, dHeight() - 5));
QOpenGLTextureBlitter: Remove Origin location for the Target rect The Origin for Target rect was deemed a confusing concept. The current implementation would translate the target rect to the coordinate system specified. However, the order and "direction" of the vertices would always be the same. So drawing a texture in for one target rect defined in one coordinate system would paint the texture the same way as it would when a texture was drawn for a target rect drawn in the "opposite" coordinate system. The point with this was that if you wanted to "flip" the texture you would specify that with the source coordinate system. However, this approach breaks on different levels, such as QRect has functions which expects a top left coordinate system (ie. top() and bottom()). In the end Qt uses a top left coordinate system, hence QWindow specifies a top left coordinate system, and hence the api becomes easier if it is not possible to define the coordinate system of the target viewport. Change-Id: I7dd59b3718380876e87a4bff88381d7a1c7d58c1 Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
2014-02-13 21:03:52 +00:00
m_image_mirrord = m_image.mirrored(false,true);
QOpenGLTextureBlitter private api, but useful for 2d gui code that suddenly finds itself needing to get a set of textures onto some fbo I didn't want to include ARB_copy_image since it looks like its from texture/renderbuffer -> texture/renderbuffer while this class implies texture -> write fbo. We could wrap ARB_copy_image in QOpenGLTexture or some other class or we can add it later. I have not added any QOpenGLTexture functions since this class opperates on the GLuint identifier. We can add overloads later. Change-Id: I3e565b33466c1c183a249a33c3e82c6786debd55 Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2014-02-02 21:29:38 +00:00
}
Reference in New Issue Copy Permalink