Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior when using LinearGradientBrush + RelativeTransform #10502

Open
dipeshmsft opened this issue Feb 25, 2025 · 2 comments · May be fixed by #10506
Open

Unexpected behavior when using LinearGradientBrush + RelativeTransform #10502

dipeshmsft opened this issue Feb 25, 2025 · 2 comments · May be fixed by #10506

Comments

@dipeshmsft
Copy link
Member

dipeshmsft commented Feb 25, 2025

Description

While working on Fluent we ran into an issue when we were trying to use LinearGradientBrush alongwith RelativeTransform and MappingMode set to Absolute.

In the issue, when we use a LinearGradientBrush defined with above properties and apply it on controls with different heights, the position of linear gradient remains the same from top, rather than from bottom.

Moreover, if a control with a different height gets processed / styled first, the position of linear gradient is now different.

The first control using the brush gets the correct styling, however subsequent controls where this is used don't see the correct style. This seems like a caching issue in the sense that once the brush is evaluated for the first control, the values of gradient stops are cached by the brush and they are not being reevaluated for other controls where the brush is used.

Reproduction Steps

Here are the steps to repro the issue :

  1. Define a LinearGradientBrush like following in your resources :
<LinearGradientBrush x:Key="FaultyBorderBrush" MappingMode="Absolute"  StartPoint="0,0" EndPoint="0,3">
    <LinearGradientBrush.RelativeTransform>
        <ScaleTransform ScaleY="-1" CenterY="0.5" />
    </LinearGradientBrush.RelativeTransform>
    <LinearGradientBrush.GradientStops>
        <GradientStop Offset="0.33" Color="Red" />
        <GradientStop Offset="1.0" Color="Orange" />
    </LinearGradientBrush.GradientStops>
</LinearGradientBrush>
  1. Now create multiple elements in your window which use the Brush ( make sure they have varying sizes ) like this :
    <StackPanel Orientation="Horizontal">
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="50" Width="50"/>
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="100" Width="50"/>
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="30" Width="50"/>
    </StackPanel>
  1. Run the application. You will get something like this on the screen :

Image

  1. Now just reorder the elements in your application, Here is what I did ( just moved border with height 30 to first position )
    <StackPanel Orientation="Horizontal">
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="30" Width="50"/>
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="50" Width="50"/>
        <Border Margin="20" BorderBrush="{DynamicResource FaultyBorderBrush}" 
                BorderThickness="10" Height="100" Width="50"/>
    </StackPanel>
  1. Run the application and observe :

Image

Expected behavior

In respect to the above example, every control no matter the height should have a red color at the bottom of the border.

Actual behavior

The brush is getting cached according to the first brush and gradient stops are not being calculated again.

Regression?

Don't know. Looks like a long standing issue.

Known Workarounds

Can avoid using Absolute MappingMode for the brush.

Impact

No response

Configuration

  • Which version of .NET is the code running on? : .NET 9 and 10
  • What OS and version, and what distro if applicable? : Windows 11
  • What is the architecture (x64, x86, ARM, ARM64)? : Tried with x64
  • Do you know whether it is specific to that configuration? : Don't think so.

Other information

I discussed this issue with @miloush around half an year ago, but raising the issue got delayed from my end.

@dipeshmsft
Copy link
Member Author

@dotnet/dotnet-wpf-triage any feedback on this issue and it's fix ?

@h3xds1nz
Copy link
Member

@dipeshmsft I'll take a look tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants