tsai/Avalonia: A cross-platform UI framework for .NET - Avalonia - Gitea: Git with a cup of tea

A cross-platform UI framework for .NET

csharp c-sharp dotnet xaml avaloniaui cross-platform cross-platform-xaml avalonia gui multi-platform user-interface dotnetcore

Branch: fixes/macos-owned-window-level-inheritance

History

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
..
Drawing_Brush_Relative_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Image_Brush_Relative_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Linear_Gradient_Relative_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Radial_Gradient_Relative_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Relative_Transform_Should_Apply_Before_Transform.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Relative_Transform_Should_Follow_The_Bounds_Of_Each_Fill.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Solid_Color_Relative_Transform_Should_Be_Ignored.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Tiled_Drawing_Brush_Relative_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago
Tiled_Image_Brush_Relative_And_Absolute_Transform_Should_Work_As_Expected.wpf.png	Add RelativeTransform to brushes (#21881)	1 week ago