Color.GetHue value return different value based on framework in WPF platform

[SubashiniMahendran]

Description

I created an application that includes a ColorHelper class which computes a color value for a SolidColorBrush based on its opacity. However, calling Color.GetHue returns slightly different values depending on the target framework (for example, .NET Framework 4.6.2 vs .NET Core), so the resulting color differs between builds. Please see the attached screenshot and sample project for reference.

wpf-462-project.zip
wpf-netcore-project.zip

Reproduction Steps

Run the attached net462 and netcore samples.
Note the color value different in both sample due to Color.GetHue value.

Expected behavior

Should return same color value for both 462 and netcore framework in Color.GetHue method.

Actual behavior

Return different color value for 462 and netcore framework in Color.GetHue method.

Regression?

No response

Known Workarounds

No response

Impact

No response

Configuration

No response

Other information

No response

[miloush]

First of all, checking the values this way is not reliable. The result of ToString() operation that you see uses general format with unspecified precision and does not necessarily show you the whole value. This is documented to vary in https://learn.microsoft.com/en-us/dotnet/standard/base-types/standard-numeric-format-strings#general-format-specifier-g where it says that for .NET Framework it defaults to G7, where G9 is required for roundtripping float values.

Note that BitConverter.GetBytes(hue) returns the same value on both platforms.

Either way, this is not WPF related issue (and Color.GetHue is not even in WPF).

Duplicate of dotnet/runtime#118059 which refers breaking change announced in https://learn.microsoft.com/en-us/dotnet/core/compatibility/3.0#floating-point-formatting-and-parsing-behavior-changed.

[miloush]

Also refer to the chapter 12.1.3 Handling of floating-point data types of ECMA-335 (5th ed):

Storage locations for floating-point numbers (statics, array elements, and fields of classes) are of fixed size. The supported storage sizes are float32 and float64. Everywhere else (on the evaluation stack, as arguments, as return types, and as local variables) floating-point numbers are represented using an internal floating-point type. In each such instance, the nominal type of the variable or expression is either float32 or float64, but its value can be represented internally with additional range and/or precision. The size of the internal floating-point representation is implementation-dependent, can vary, and shall have precision at least as great as that of the variable or expression being represented. An implicit widening conversion to the internal representation from float32 or float64 is performed when those types are loaded from storage. The internal representation is typically the native size for the hardware, or as required for efficient implementation of an operation. The internal representation shall have the following characteristics:

• The internal representation shall have precision and range greater than or equal to the nominal type.
• Conversions to and from the internal representation shall preserve value.

In other words, CLR is allowed to use larger precision to represent float values, as long as the value of float32 precision remains the same, and the internal type/precision is explicitly allowed to change (and it might differ based on hardware, JIT etc.). You can see this happening yourself. Do for example hue.ToString("G30"), and you will get much longer number (I get 5.357142925262451171875 on .NET 9 but not in .NET FW). However, on all the platforms, G9 returns the same number as expected.