Add QQuickPathItem and its backend infra
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>
2016-12-03 20:30:12 +00:00
|
|
|
<RCC>
|
2017-07-28 09:28:57 +00:00
|
|
|
<qresource prefix="/shapes">
|
Add QQuickPathItem and its backend infra
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>
2016-12-03 20:30:12 +00:00
|
|
|
<file alias="LauncherList.qml">../shared/LauncherList.qml</file>
|
|
|
|
|
<file alias="SimpleLauncherDelegate.qml">../shared/SimpleLauncherDelegate.qml</file>
|
|
|
|
|
<file alias="images/next.png">../shared/images/next.png</file>
|
|
|
|
|
<file alias="images/back.png">../shared/images/back.png</file>
|
2017-03-17 13:22:24 +00:00
|
|
|
<file alias="images/slider_handle.png">../shared/images/slider_handle.png</file>
|
2017-07-28 09:28:57 +00:00
|
|
|
<file alias="main.qml">content/main.qml</file>
|
|
|
|
|
<file alias="shapegallery.qml">content/shapegallery.qml</file>
|
|
|
|
|
<file alias="interactive.qml">content/interactive.qml</file>
|
|
|
|
|
<file alias="sampling.qml">content/sampling.qml</file>
|
|
|
|
|
<file alias="clippedtigers.qml">content/clippedtigers.qml</file>
|
2017-01-08 13:47:27 +00:00
|
|
|
<file alias="tiger.qml">content/tiger.qml</file>
|
QQuickShape: override contains(QPointF); demonstrate in examples
QQuickItem::contains() only checks the Item's bounding box by default.
In the case of Shapes, that can be comically imprecise, but it's fast.
So we add a containsMode property to control whether we will do that
(the default) or actually check each of the QPainterPaths within to
see whether they contain the point (FillContains).
FillContains could be optimized later: use QRegion perhaps, or download
the rendered texture from the GPU and test whether the pixel at the
point is transparent. It may also be appropriate to add a StrokeContains
option.
The main motivation is to detect mouse (or touch) interaction within
a shaped area. QQuickSinglePointHandler::wantsEventPoint() already
checks whether its parent Item contains the event point. So if a
Shape has a TapHandler for example, it will respond only within the
visible bounds of the Shape rather than within the entire rectangular
bounding box as long as containsMode is set to FillContains.
Examples quick/shapes/content/tapableTriangle.qml and tiger.qml
are modified to react when a press occurs inside, and the former
is fixed to be able to run standalone via the qml runtime. The
latter has an offset issue when run standalone but is OK within
the shape gallery example.
As a drive-by optimization, QQuickShapePrivate's variables are
re-ordered by type so that the compiler can place the bools and
enums into bitfields; and to facilitate reordering, the
initialization is done C++11-style, in the header.
[ChangeLog][QtQuick][Shape] A containsMode property is added.
If it is set to FillContains, then Shape.contains() returns true
only within the visible bounds, so its Pointer Handlers also respond
only within those bounds.
Change-Id: I31c85a9b08aa6945c58dc07febfe89ffef21274b
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
2017-09-22 20:48:25 +00:00
|
|
|
<file alias="tapableTriangle.qml">content/tapableTriangle.qml</file>
|
Add QQuickPathItem and its backend infra
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>
2016-12-03 20:30:12 +00:00
|
|
|
<file alias="item2.qml">content/item2.qml</file>
|
2017-07-28 11:44:09 +00:00
|
|
|
<file alias="item3.qml">content/item3.qml</file>
|
Add QQuickPathItem and its backend infra
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>
2016-12-03 20:30:12 +00:00
|
|
|
<file alias="item4.qml">content/item4.qml</file>
|
|
|
|
|
<file alias="item5.qml">content/item5.qml</file>
|
|
|
|
|
<file alias="item6.qml">content/item6.qml</file>
|
|
|
|
|
<file alias="item7.qml">content/item7.qml</file>
|
|
|
|
|
<file alias="item8.qml">content/item8.qml</file>
|
|
|
|
|
<file alias="item9.qml">content/item9.qml</file>
|
|
|
|
|
<file alias="item10.qml">content/item10.qml</file>
|
|
|
|
|
<file alias="item11.qml">content/item11.qml</file>
|
|
|
|
|
<file alias="item12.qml">content/item12.qml</file>
|
2017-01-04 13:15:45 +00:00
|
|
|
<file alias="item13.qml">content/item13.qml</file>
|
|
|
|
|
<file alias="item14.qml">content/item14.qml</file>
|
|
|
|
|
<file alias="item15.qml">content/item15.qml</file>
|
2017-01-04 14:12:32 +00:00
|
|
|
<file alias="item17.qml">content/item17.qml</file>
|
2020-01-15 10:53:35 +00:00
|
|
|
<file alias="item18.qml">content/item18.qml</file>
|
Add QQuickPathItem and its backend infra
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>
2016-12-03 20:30:12 +00:00
|
|
|
</qresource>
|
|
|
|
|
</RCC>
|
