| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| | |
Change-Id: Iea0bb0788357bc615d0e9ea411087114b8b3b720
|
| | |\
| | |
| | |
| | | |
Change-Id: I71275a2076c3d32ee2896571be882067320a2e9e
|
| | | |
| | |
| | |
| | |
| | | |
Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |\| |
| | |
| | |
| | | |
Change-Id: I0cbb2ba4a00580e6a74a4e4085fc4eb06d0fadae
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
After the previous cleanups, it became clear that this didn't serve much
of a purpose, so let's remove it and simplify the implementation as a
result.
Change-Id: Iae2ff9c46762f0c7bdf4225a2c4df93bc8253902
Reviewed-by: Yoann Lopes <yoann.lopes@qt.io>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic backend uses the triangulator from QtGui, but is in
fact OpenGL-only for now due to materials.
The NVPR backend uses GL_NV_path_rendering on NVIDIA hardware with
OpenGL 4.3+ or OpenGL ES 3.1+.
The software backend simply uses QPainter.
With the generic backend each PathItem is backed by a non-visual root node
and 0, 1 or 2 child geometry nodes, depending on the presence of visible
stroking and filling. The potentially expensive triangulation happens on
updatePolish(), on the gui thread. This is proven to provide much smoother
results when compared to doing the geometry generation on the render thread
in updatePaintNode(), in particular on power-limited embedded devices.
The NVPR backend uses a QSGRenderNode in DepthAware mode so that the batch
renderer can continue to rely on the depth buffer and use opaque batches.
Due to not relying on slow CPU-side triangulation, this backend uses 5-10
times less CPU, even when properties of the path or its elements are
animated.
The path itself is specified with the PathView's Path, PathLine, PathArc,
PathQuad, etc. types. This allows for consistency with PathView and the
2D Canvas and avoids a naming mess in the API. However, there won't be a
100% symmetry: backends like NVPR will not rely on QPainterPath but process
the path elements on their own (as QPainterPath is essentially useless with
these APIs), which can lead to differences in the supported path elements.
The supported common set is currently Move, Line, Quad, Cubic, Arc.
The patch introduces PathMove, which is essentially PathLine but maps to
moveTo instead of lineTo. More types may get added later (e.g. NVPR can do
a wide variety of optimized rounded rects, but this requires directly
specifying a GL_ROUNDED_RECTx_NV command, thus neededing a dedicated Path
type on our side too)
For filling with gradients only linear gradients are supported at the
moment.
In addition to the declarative API, a more lightweight, QObject-less
JS-callable API should be considered as well for the future.
Change-Id: I335ad64b425ee279505d60e3e57ac6841e1cbd24
Reviewed-by: Andy Nichols <andy.nichols@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>
|
