[robloo]

What does the pull request do?

Fixes the comments in PreciseArcTo() which incorrectly define the input rotationAngle units as radians isntead of degrees.

This matches the discussions here:

• GeometryBuilder.DrawRoundedCornersRectangle passes corner-arc rotation in radians; only renders correctly because the Skia backend treats it as degrees #21445 (comment)
• Fix GeometryBuilder.DrawRoundedCornersRectangle for Rect #21482 (comment)

What is the current behavior?

Comments list radians instead of degrees.

What is the updated/expected behavior with this PR?

Comments are updated to mention degrees (which is being used already in the math). Comments were updated by inheriting existing text where possible.

How was the solution implemented (if it's not obvious)?

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

None. Access modifiers were made explicitly internal in the static PreciseEllipticArcHelper helper but this isn't a change. Within that helper, EllipticalArc was restricted to private but that isn't an issue since it was within the internal helper.

Obsoletions / Deprecations

None

Fixed issues

Related to #21445

[github-actions]

NuGet packages

The packages for this pull request have been published (workflow run):

• Version: 12.2.999-cibuild0100323-alpha
• Feed URL: https://nuget-feed-all.avaloniaui.net/v3/index.json

[MrJul]

While I usually don't mind some unneeded spaces being automatically removed, in this PR, the code reformatting makes up the majority of the changes. Please revert that.

(We'll have some proper solution-wide reformatting and style enforcement at some point.)

[robloo]

@MrJul The code reformatting here actually fixes wrong indentation which affects readability quite a bit when going through that particular code. I couldn't at-a-glance tell the nesting when I was adjusting access modifiers. I restrained myself quite a bit as far as formatting corrections go. Whether the format change is larger than the code change is largely irrelevant as long as they are both targeted. It is not difficult to review.

The core teams aversion to formatting fixes is disappointing when there are clear, universally agreed C# formatting rules that the project simply doesn't follow. For everyone's benefit these need to get fixed and PR after PR is called out for fixing them. I think this needs to be re-assessed...

As far as automatic formatting I've heard about that for over 5 years now. It was supposed to happen for 12.0. It's desperately needed and things like XAMLStyler setup is very easy at this point. It doesn't take more than an hour.