Avalonia

Branch: main

Commit Graph

Author	SHA1	Message	Date
Benedikt Stebner	0dbce40347	Add RelativeTransform to brushes (#21881 ) * Apply tile brush transforms once the tile sits in target space Brush.Transform was concatenated into the shader matrix before the translation that moves the tile onto the painted area, so it acted in the tile's own space instead of the target's. A brush transform on a fill away from the origin - the common case, since a relative viewport resolves against the fill's bounds - came out displaced, and WPF, whose behaviour these brushes follow, disagrees. Both tile paths now place the tile first and let the transform act on the result. Where the placement is identity, which is what the existing goldens cover, the matrices are unchanged. The cross suite gains an image brush so the non-scalable path is covered too, plus a smooth ramp fixture: the star line drawing that was the only image asset survives resampling as sparse speckle, which the comparison metric cannot tell apart from a geometry error. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Apply the conic gradient transform after its angle The sweep shader carried Angle as its local matrix and pre-concatenated Brush.Transform onto it, so the transform acted on the raw sweep and the angle then turned the result. Every other brush bakes its intrinsic geometry in first and lets the brush transform act on the finished pattern. The visible effect was that a translation moved the gradient in a direction rotated by Angle - 90 instead of the direction asked for. A sweep gradient is fully determined by its centre and angle, so the golden here is checked against the brush with its centre moved by the same offset and no transform: the two renders are pixel-identical, while the previous order is 0.169 rmse away against a 0.022 tolerance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Add RelativeTransform to every brush A brush transform expressed in the unit space of the painted bounds, applied before the absolute Transform - WPF's Brush.RelativeTransform. It lets one brush express a bounds-dependent transform, an SVG gradientTransform in objectBoundingBox units for instance, without baking any one consumer's bounds into a matrix, which is what makes a single brush per gradient definition possible. The property sits on IBrush and Brush, so every brush kind carries it and a consumer reads it without a type test. Each immutable brush takes it through a second constructor, leaving the existing signatures alone and marking them for collapse in v13. The gradient brush animator interpolates it alongside Transform, and the composition schema gains it on both brush bases so the value reaches the render thread as a live resource rather than a snapshot. IBrush is NotClientImplementable, so the added member is suppressed for API validation the way earlier additions to those interfaces are. Nothing consumes it yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Consume RelativeTransform in the Skia backend The relative matrix is conjugated into target space at draw time - the unit square maps onto the painted rect, whose origin translation and scale wrap the matrix - and composes before the absolute brush transform. All three gradient kinds and both tile brush paths read it; a solid colour brush has nothing for it to act on, matching WPF. With no relative transform every path reduces to the previous matrices, so existing goldens stay byte-identical. The cross suite compares the result against WPF for the linear and radial gradients, a drawing brush tiled and untiled, an image brush, the composition order against Transform, one brush shared by two differently sized fills, and the solid colour no-op. Goldens under Skia/Media additionally cover the immediate renderer and the GPU backends, which the cross suite does not exercise; each was measured against its WPF counterpart before being committed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	1 week ago

Author

SHA1

Message

Date

Benedikt Stebner

0dbce40347

Add RelativeTransform to brushes (#21881 )

* Apply tile brush transforms once the tile sits in target space

Brush.Transform was concatenated into the shader matrix before the
translation that moves the tile onto the painted area, so it acted in
the tile's own space instead of the target's. A brush transform on a
fill away from the origin - the common case, since a relative viewport
resolves against the fill's bounds - came out displaced, and WPF, whose
behaviour these brushes follow, disagrees.

Both tile paths now place the tile first and let the transform act on
the result. Where the placement is identity, which is what the existing
goldens cover, the matrices are unchanged.

The cross suite gains an image brush so the non-scalable path is
covered too, plus a smooth ramp fixture: the star line drawing that was
the only image asset survives resampling as sparse speckle, which the
comparison metric cannot tell apart from a geometry error.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Apply the conic gradient transform after its angle

The sweep shader carried Angle as its local matrix and pre-concatenated
Brush.Transform onto it, so the transform acted on the raw sweep and
the angle then turned the result. Every other brush bakes its intrinsic
geometry in first and lets the brush transform act on the finished
pattern.

The visible effect was that a translation moved the gradient in a
direction rotated by Angle - 90 instead of the direction asked for. A
sweep gradient is fully determined by its centre and angle, so the
golden here is checked against the brush with its centre moved by the
same offset and no transform: the two renders are pixel-identical,
while the previous order is 0.169 rmse away against a 0.022 tolerance.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Add RelativeTransform to every brush

A brush transform expressed in the unit space of the painted bounds,
applied before the absolute Transform - WPF's Brush.RelativeTransform.
It lets one brush express a bounds-dependent transform, an SVG
gradientTransform in objectBoundingBox units for instance, without
baking any one consumer's bounds into a matrix, which is what makes a
single brush per gradient definition possible.

The property sits on IBrush and Brush, so every brush kind carries it
and a consumer reads it without a type test. Each immutable brush takes
it through a second constructor, leaving the existing signatures alone
and marking them for collapse in v13. The gradient brush animator
interpolates it alongside Transform, and the composition schema gains
it on both brush bases so the value reaches the render thread as a live
resource rather than a snapshot.

IBrush is NotClientImplementable, so the added member is suppressed for
API validation the way earlier additions to those interfaces are.

Nothing consumes it yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Consume RelativeTransform in the Skia backend

The relative matrix is conjugated into target space at draw time - the
unit square maps onto the painted rect, whose origin translation and
scale wrap the matrix - and composes before the absolute brush
transform. All three gradient kinds and both tile brush paths read it;
a solid colour brush has nothing for it to act on, matching WPF. With
no relative transform every path reduces to the previous matrices, so
existing goldens stay byte-identical.

The cross suite compares the result against WPF for the linear and
radial gradients, a drawing brush tiled and untiled, an image brush,
the composition order against Transform, one brush shared by two
differently sized fills, and the solid colour no-op. Goldens under
Skia/Media additionally cover the immediate renderer and the GPU
backends, which the cross suite does not exercise; each was measured
against its WPF counterpart before being committed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

1 week ago

1 Commits (main)