| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QSvgRenderer already obeys the QPen::isCosmetic() setting.
Now we add a ShapePath.cosmeticStroke property and try to support
cosmetic stroking both with SVG and with Shapes, in all renderers.
The curve renderer now starts with skinny triangles: each segment's end
vertices are passed to the vertex shader with their original positions,
and the shader uses the normal and the stroke width to expand the stroke
triangles outwards as needed. We always add triangles for end caps,
regardless whether they are square or round. We get rid of
addBevelTriangle and fix bevels, square caps and miters:
All three of these cases are done by drawing lines adjusted to the
right direction within the respective triangles. And to avoid seeing
rounded ends at any reasonable zoom level, we need the line equation
coefficients to take the line very far outside the actual triangles.
Square caps are really square: we render line segments in those three
triangles, not extensions of the adjacent curve or line.
Miters are also rendered as straight tangent lines.
The bevel's triangle is very short when the join is an acute angle,
and almost as tall as the full stroke width when the join is very
obtuse. But when the triangle is short, we need to diminish the stroke
width rendered in the fragment shader so that the center of the stroke
falls on the inner corner of that triangle, and the edge of the stroke
is rendered along the outer bevel edge rather than trying to go outside.
That's achieved by multiplying the stroke width by the cosine of half
the total angle, AKA the dot product. That is now in the normalExt.z
vertex attribute.
Normals (normalExt.xy) can be premultiplied rather than normalized:
in fact some of them already have length > 1.
In qsgbatchrenderer, Renderer::prepareAlphaBatches() breaks batches
when overlaps occur. Now that we stroke lines with vertices that
represent them as zero-width lines (and thus Element.bounds has
the same x or y coordinates on both corners), we must consider lines
right on top of each other to be overlapping: e.g. the stacks of
horizontal (dashed) line segments in paint-stroke-202-t.svg must be
in separate batches.
At the time QQuickShape::updatePaintNode() is called, the available
transform node (from UpdatePaintNodeData or an individual node's parent
which is a transform node) does not contain the scaling factor that we
need to allow for the stroke width to be adjusted for cosmetic stroking.
But in QQuickShapePrivate::sync(), windowToItemTransform() is known, and
from bde55ad574ac84440e2cdc9c1122a344bb1cb67a we have a precedent in
QSGCurveStrokeMaterialShader::updateUniformData() for using the square
root of the matrix determinant as a scaling approximation (ok when the
scaling is uniform). QQuickShapeSoftwareRenderer::setNode() was already
adjusting a path's bounding rect by its stroke width, and we need a
multiplicative factor there to account for cosmetic stroking, to avoid
excessive clipping in the software renderer. So now we have another use
for the triangulationScale that was introduced in
bcfcaeb87be783d8c329b0bc96323f1c9863982d.
When QQShapeGenericRenderer is used (rendererType == GeometryRenderer),
and any ShapePath has cosmeticStroke, we need it to re-triangulate
whenever scale changes. QQuickShapeGenericRenderer::triangulateStroke()
calls QTriangulatingStroker::setInvScale(1 / triangulationScale), and
QTriangulatingStroker::process() multiplies its m_width by the inverse
scale that was set (since 2009). So this tells us that the intended
meaning of triangulationScale is the inverse of the factor by which we
multiply the pen width. And when QQShapeGenericRenderer is in use,
and there are cosmetic strokes, QQuickShape::itemChange triggers
re-triangulation on changes in scale.
When setting the QQuickShapeCurveRenderer::DebugWireframe debug
visualization flag, we need to repeat the vertex shader calculations to
expand the "skinny" triangles according to stroke width, just as we do
with the actual stroking vertices.
For now customTriangulator2 remains as legacy code, to be removed later
on. It's poorly named, and returns a list of TriangleData which need to
be iterated afterwards ("fix it in post"), looking up the
QQuadPath::Element again in that second loop, which can go wrong when a
path contains a move command. (For example, it could calculate a bevel
between the end-tangent of one subpath and the start-tangent of the
next.) customTriangulator2() was called from only one place,
processStroke(), to which addStrokeTriangleCallback() is given: so the
new way is to just call the callback directly as soon as we've
calculated each triangle. Because we are not iterating again afterwards,
the switch(type) is not needed in that case, and we no longer need
TriangleData::type, except for supporting customTriangulator2().
[ChangeLog][QtQuick][Shapes] ShapePath now has a cosmeticStroke
property which causes strokeWidth to be constant despite scaling.
Set the environment variable QT_QUICKSHAPES_STROKE_EXPANDING to 1 to
enable an experimental method of expanding strokes in the vertex shader,
minimizing the need to re-triangulate when strokeWidth changes.
Task-number: QTBUG-124638
Change-Id: I4eac0ddcd6f623b79bc70c766ff116f4b77736cb
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
