| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
I am not sure why this hasn't failed in CI, but the function is
declared inside the namespace, so the definition needs to go in
there as well. Seems to be a merge error all the way back to 5.8.
Change-Id: Iedd25d3e9e756c55cc302da90bab11535bdc1b01
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
| |
Change-Id: I14ee97ee75664c5dfcd229a5be2be6294c936b2c
Task-number: QTBUG-55496
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conflicts:
examples/quick/quickwidgets/quickwidget/main.cpp
src/qml/jsruntime/qv4jsonobject.cpp
src/qml/jsruntime/qv4qobjectwrapper.cpp
src/qml/jsruntime/qv4qobjectwrapper_p.h
src/qml/qml/qqmlengine.cpp
src/qml/qml/qqmlpropertycache.cpp
src/qml/qml/qqmlpropertycache_p.h
src/quick/items/qquickanimatedsprite.cpp
src/quick/items/qquickitem.cpp
src/quick/items/qquickitem.h
src/quick/items/qquickitem_p.h
src/quick/items/qquickview_p.h
src/quick/scenegraph/qsgcontext.cpp
src/quick/scenegraph/qsgdefaultrendercontext.cpp
Change-Id: I172c6fbff97208f21ed4c8b6db3d1747a889f22b
|
|
|
|
|
|
|
|
|
| |
If a QQuickWidget is somehow deleted below a QApplication post-routine
it may end up being deleted after QQuickRenderControlPrivate::cleanup(),
which means its QSGContext is deleted.
Change-Id: I396d236f997b7b68a96f8fdddd7d6c3fe31c10b0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling invalidate() from the destructor is a bad idea since what we get
is the QSGRenderContext implementation, not the one from the more-derived
class. (it could have been intentional as well - it is confusing in any case
and unnecessary).
There is no adaptation relying in this anyways - invalidate() is always
invoked manually, typically from windowDestroyed. This is very good since it
avoids the at first less-than-obvious trouble with emitting invalidated()
from the rendercontext dtor. (that can in turn can trigger random amount of
code potentially calling back into the rendercontext and rely on virtuals
which are not functional anymore due to the vtable not there for the
functions in the more-derived class)
Change-Id: I44d78c5a819230f7006d33d4341eff45d8f77c88
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Allow calling initialize(nullptr) regardless of which scenegraph backend
is in use.
Change-Id: Ie5965dcd12d423255d5eb85fed255107cac2acb9
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
Currently the Qt Quick module depends on either the OpenGL or OpenGLES
headers being available at build time. Since we are adding support for
adaptations that do not depend on OpenGL, it should be possible to build
Qt Quick in environments that do not have OpenGL development headers.
This does present many challenges though because in some cases GL types,
and classes that require OpenGL are part of the public APIs. However
since these classes were never available when QT_NO_OPENGL was defined,
it should be possible to redefine the function signatures under this
scenario, since it's not possible to break binary compatibility if there
never were any binaries to break compatibility with.
One of the bigger changes that was necessary to facilitate this change
is creating interfaces out of QSGContext and QSGRenderContext. Here the
default behavior was usage of OpenGL directly, even though subclasses
could override all OpenGL usage. Making them interfaces should bring
QSGContext and QSGRenderContext more in line with the other classes
present in the adaptation layer.
Change-Id: Iaa54dc0f6cfd18d2da1d059548abf509bd71f200
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|