summaryrefslogtreecommitdiffstats
path: root/src/opengl/qopenglvertexarrayobject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Avoid including qopenglfunctions header files if Qt is built with GLES2Alexey Edelev2022-06-281-2/+5
| | | | | Change-Id: I3a7a69f5eef604408713934811efb984e78d68dd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | 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>
* Revive eglfs' raster window supportLaszlo Agocs2022-04-271-1/+1
| | | | | | | | | | | | | | | | | | | A number of consequences of the new rhi-based backingstore composition were not handled. Most importantly, the fact that RasterGLSurface is not a thing anymore in practice causes challenges because we can no longer decide just based on the surfaceType what a QWindow with OpenGLSurface would be. (a plain GL window or a GL window with a backing store?) Also, the backingstore needs to be able to initialize its backing QRhi by itself, because with eglfs going through OpenGL is the only way. Amends 68a4c5da9a080101cccd8a3b2edb1c908da0ca8e Fixes: QTBUG-102750 Change-Id: Ia1ca59d01e3012264a76b50e591612fdcc2a0bd6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Enable access to the VAO resolvers through QOpenGLContextPrivateGiuseppe D'Angelo2020-06-221-27/+41
| | | | | | | | | | | | | | | | | | | This is a commit in preparation for an upcoming change in QtQuick. We want to store the resolved functions for managing VAOs somewhere; the "least worst" choice is next to the all other function resolvers, which are in QOpenGLContext(Private). To avoid moving the VAO resolvers themselves, leave a hook in QOGLCPrivate, similar to e.g. the texture function resolvers. The hook gets populated when the VAO resolvers for a given context are requested. This removes memory management burden from the users of those functions (again, just like other function resolvers), and makes the initialization of the functions automatic. Change-Id: I0eba30a85bf8ad82946a5d68e91009d8b4bd91cf Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Long live std::pair!Giuseppe D'Angelo2020-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make QPair an alias for std::pair, and qMakePair just a forwarder towards std::make_pair. Why? Fundamentally to ditch a bunch of NIH code; gain for free structured bindings, std::tuple and std::reference_wrapper compatibility, and so on. Breakages: * Some that code manually forward declares QPair. We don't care about it (<QContainerFwd> is the proper way). * Some code that overloads on std::pair and QPair. Luckily it's mostly centralized: debug, metatypes, testing macros. Just remove the QPair overload. * Usages of qMakePair forcing the template type parameters. There are a handful of these in qtbase, but only one was actually broken. * std::pair is NOT (and will never likely be) trivially copiable. This is agreed to be a mistake done by practically all implementations in C++11, can can't be fixed without breaking ABI. Some code using QPair assuming it's trivially copiable may break; exactly one occurrence was in qtbase. * QMetaType logic extracts the type names in two different ways, one by looking at the source code string (e.g. extracted by moc) and one via some ad-hoc reflection in C++. We need to make "QPair" (as spelled in the source code) be the same as "std::pair" (gathered via reflection, which will see through the alias) when compared. The way it's already done e.g. for QList is by actually replacing the moc-extracted name with the name of the actual type used in C++; do the same here. On libc++, std::pair is actually in an inline namespace -- i.e. std::__1::pair; the reflection will extract and store "std::__1::pair" so we need an ad-hoc fix to QMetaType. [ChangeLog][QtCore][QPair] QPair is now an alias to std::pair, and does not exist as a class in Qt any more. This may break code such as functions overloaded for both QPair and std::pair. Usually, the overload taking a QPair can be safely discarded, leaving only the one taking a std::pair. QPair API has not changed, and qMakePair is still available for compatibility (although new code is encouraged to use std::pair and std::make_pair directly instead). Change-Id: I7725c751bf23946cde577b1406e86a336c0a3dcf Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Avoid using qGuiApp in QOpenGLVao::destroy()Laszlo Agocs2020-04-211-1/+5
| | | | | | | | | | | | | There are convoluted cases, based on the backtrace attached to the associated bug report, where we attempt to destroy a QOpenGLVertexArrayObject during the destruction of Q(Gui)Application. Just avoid accessing qGuiApp in destroy(). Rather, store it in create(). Fixes: QTBUG-75138 Pick-to: 5.15 Change-Id: If8e67301c0843cbf3a409dcf427f44c42079de2f Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Get rid of QT_OPENGL_ES*Eskil Abrahamsen Blomfeldt2020-04-171-4/+4
| | | | | | | | | | | The QT_OPENGL_ES* macros are leftovers from an earlier, ad hoc configuration system, which has since been replaced by QT_CONFIG. To clean things up in Qt 6, we use the new way instead. Task-number: QTBUG-83467 Change-Id: I578dc7695bff9d5ee303b22e44f60fee22fe0c28 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move versioned OpenGL functions from QtGui to QtOpenGLJohan Klokkhammer Helsing2020-04-161-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The context—which lives in QtGui—now knows nothing about versioned functions. This changes the public API for getting version functions for a context. [ChangeLog][QtGui][OpenGL] QOpenGLContext::versionFunctions() has been removed. QOpenGLVersionFunctionsFactory::get() from the QtOpenGL module should be used instead. Previously one would call context->versionFunctions<QOpenGLFunctions_4_0_Core>(); Which now becomes QOpenGLVersionFunctionsFactory::get<QOpenGLFunctions_4_0_Core>(context); The rest of the API should be identical. Since glgen no longer compiles, and the links to its input (gl.spec and gl.tm) are dead, I've edited the previously generated files manually. If glgen is fixed, it should be quite easy to make it generate the new way. Task-number: QTBUG-74409 Change-Id: I800527e0af16a79005b276eeb74417770193c62f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Move QOpenGLVertexArrayObject from QtGui to QtOpenGLJohan Klokkhammer Helsing2020-02-211-0/+531
Task-number: QTBUG-74409 Change-Id: I6442693ca2b28b3a66f0f4fb41843e1e404df32b Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>