Skip to content

Fix measuring passes in AdornerLayer of the underlying Adorner elements #10657

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

h3xds1nz
Copy link
Member

@h3xds1nz h3xds1nz commented Mar 26, 2025

Fixes #10640

Description

Marks AdornerLayer dirty when any of the Adorners is dirty and forces a measure pass so that the position is updated.

Due to the aggressive performance optimization to only re-render when size/position changes (including transforms),
a case such as this has been overlooked so the position of the respective Adorner's is wrong while all flags are correct.

This could have been workarounded via synchronous UpdateLayout pass called by the user or invoking visual re-invalidation but due to its asynchronous nature this would only work the second time around.

I have also removed the redundant assigment of cached RenderSize/Transform and in-lined the two calls instead.

This shall not add any unnecessary overhead according to my testing.

Customer Impact

If the fix is not taken, customers will continue to observe unwanted behaviour and will be required to use computionally expensive and synchronous updates to receive the correct position for Adorners upon adorned UIElement changes.

Regression

Not according to my tests, this seems to be present both on .NET Core and NETFX.

Testing

Local build, repro tests from #10640, tests with adorners.

Risk

Medium, it would be beneficial to test more real-life examples of adorners.

Microsoft Reviewers: Open in CodeFlow

@h3xds1nz h3xds1nz requested review from a team as code owners March 26, 2025 15:59
@dotnet-policy-service dotnet-policy-service bot added PR metadata: Label to tag PRs, to facilitate with triage Community Contribution A label for all community Contributions labels Mar 26, 2025
@h3xds1nz h3xds1nz requested a review from miloush March 26, 2025 16:01
Copy link

codecov bot commented Mar 26, 2025

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Project coverage is 11.39704%. Comparing base (6514196) to head (e04f31c).
Report is 5 commits behind head on main.

Additional details and impacted files
@@                 Coverage Diff                 @@
##                main      #10657         +/-   ##
===================================================
+ Coverage   11.22814%   11.39704%   +0.16890%     
===================================================
  Files           3352        3353          +1     
  Lines         668000      668068         +68     
  Branches       74980       74981          +1     
===================================================
+ Hits           75004       76140       +1136     
+ Misses        591745      590585       -1160     
- Partials        1251        1343         +92     
Flag Coverage Δ
Debug 11.39704% <0.00000%> (+0.16890%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community Contribution A label for all community Contributions PR metadata: Label to tag PRs, to facilitate with triage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adorner Initial Position Incorrect After Foreground Color Change
2 participants