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

[WinUI] Optimize TransformationExtensions #22481

Conversation

MartyIX
Copy link
Contributor

@MartyIX MartyIX commented May 17, 2024

Description of Change

This PR makes it so that RenderTransform property is not set unnecessarily just to be unset immediately after. Setting RenderTransform seems very costly.

All UI elements that do not need RenderTransform will benefit from this change. For example, creating biggish grids or more complex apps where inefficiencies add up.

Speedscope

1st measurement

image

-> 75% improvement

I need to double check the results because it seems "too much".

2nd measurement

image

-> 87% improvement

Issues Fixed

Contributes to #21787

@dotnet-policy-service dotnet-policy-service bot added the community ✨ Community Contribution label May 17, 2024
Copy link
Contributor

Hey there @MartyIX! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

Comment on lines -21 to -22
frameworkElement.RenderTransformOrigin = new global::Windows.Foundation.Point(anchorX, anchorY);
frameworkElement.RenderTransform = new ScaleTransform { ScaleX = scaleX, ScaleY = scaleY };
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically this is set to be unset on L27 and L28.

Additionaly, my best guess is that unsetting RenderTransformOrigin is not necessary if RenderTransform is not null.

@MartyIX MartyIX marked this pull request as ready for review May 17, 2024 10:50
@MartyIX MartyIX requested a review from a team as a code owner May 17, 2024 10:50
Comment on lines 21 to 20
if (rotationX % 360 == 0 && rotationY % 360 == 0 && rotation % 360 == 0 &&
translationX == 0 && translationY == 0 && scaleX == 1 && scaleY == 1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are all default, this if should be true.

But are there cases were we need to round? What if someone did some math in their code and rotationX is 359.99999999?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

I'm not too sure what conventions MAUI or graphics libraries have in this regard. Naively I would say that 359.999999 is not really a big issue because it probably happens quite rarely and function-wise the result will be acceptable (yet slower in performance).

If you have a specific suggestion, please suggest it here. Otherwise, I would like to avoid mixing multiple things in one PR (because it can add months to get this merged). This PR is mostly meant for elements that does no transformations at all (my use case) and I believe it's very very common.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe someone like @PureWeen or @mattleibow know of an example where we round on other platforms.

I imagine an extension method for double like: IsNearly(0, translationX) or IsNearly(1, scaleX) if we already do this somewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine an extension method for double like: IsNearly(0, translationX) or IsNearly(1, scaleX) if we already do this somewhere.

Sure, I understand the idea. I'm just not sure how exactly to implement it so that it can be considered "always correct" (like how many decimals, etc.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed #22513 for this.

@MartyIX MartyIX force-pushed the feature/2024-05-17-TransformationExtensions-Optimization-FINAL branch from 93cbade to 2344995 Compare May 17, 2024 14:33
@jsuarezruiz
Copy link
Contributor

/azp run

Copy link

Azure Pipelines successfully started running 3 pipeline(s).

@Eilon Eilon added the area-animation Animation, Transitions, Transforms label May 20, 2024
@MartyIX
Copy link
Contributor Author

MartyIX commented May 21, 2024

@rmarinho Could you take a look please?

@MartyIX MartyIX added the t/perf The issue affects performance (runtime speed, memory usage, startup time, etc.) (sub: perf) label May 22, 2024
@MartyIX
Copy link
Contributor Author

MartyIX commented May 22, 2024

@Eilon I would say that area-animation is not a correct label here. This PR makes it so that RenderTransform property is not set unnecessarily just to be unset immediately after. Setting RenderTransform seems very costly.

My test app does not contain any animation whatsoever, it just contains a biggish grid. So this PR should help everyone who does not use animations.

edit: Improved OP.

@Eilon
Copy link
Member

Eilon commented May 22, 2024

@Eilon I would say that area-animation is not a correct label here. This PR makes it so that RenderTransform property is not set unnecessarily just to be unset immediately after. Setting RenderTransform seems very costly.

My test app does not contain any animation whatsoever, it just contains a biggish grid. So this PR should help everyone who does not use animations.

edit: Improved OP.

Ah, OK. If you know a better area can you suggest/update it? Otherwise I think area-animation is OK because it's an animation/transformation API that has a 'bug' in it, so I think it's a good fit? But, this isn't an area I'm very familiar with...

@MartyIX
Copy link
Contributor Author

MartyIX commented May 22, 2024

I added the t/perf label earlier. Now it's OK, I think.

@PureWeen PureWeen merged commit a7705a9 into dotnet:main May 23, 2024
49 checks passed
@MartyIX MartyIX deleted the feature/2024-05-17-TransformationExtensions-Optimization-FINAL branch May 24, 2024 05:25
@github-actions github-actions bot locked and limited conversation to collaborators Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-animation Animation, Transitions, Transforms community ✨ Community Contribution fixed-in-8.0.60 fixed-in-9.0.0-preview.5.24307.10 t/perf The issue affects performance (runtime speed, memory usage, startup time, etc.) (sub: perf)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants