Corrupt radial gradient on Apple Silicon

[lmdsp]

I've encountered a strange bug when rendering an svg with certain focal point values.
Strangely enough, the rendering is correct on Intel x64 (mac/PC) and the online ThorVG viewer,
but Apple Silicon / ARM show weird horizontal lines instead of the expected gradient.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="800" height="590" version="1.1" id="svg13" xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
   <defs>
      <radialGradient cx="429" cy="3" fx="429" fy="-600" gradientUnits="userSpaceOnUse" id="b" r="600">
         <stop offset="0" stop-color="red" id="stop10" />
         <stop offset="1" stop-color="white" id="stop11" />
      </radialGradient>
   </defs>

   <path d="M 800,200 H 0 V 590 H 800 V 0 Z" fill="url(#b)" id="svg_4" />
</svg>

Note that if fx is changed to 600, then there are no artefacts anymore.
This is using latest ThorVG 0.12.6, XCode 15.2 and macos Sonoma 14.3.1.

ThorVG viewer:

Test application | x64:

Test application | Apple Silicon:

[mgrudzinska]

@lmdsp could you please try after this slight change?
#2018
this is a random guess since for now I'm able to test on apple silicon.

Also could you please test what will happen if you change fy="-600" to fy="-597" ?

[lmdsp]

@mgrudzinska Thanks for looking into this.

Changing from fy="-600" to fy="-597" doesn't change anything.
Changing line 207 from if (fill->radial.a > 0); to if (fill->radial.a > RADIAL_A_THRESHOLD); doesn't fix the problem either I'm afraid.

Perhaps a hint; those are the contents before and after executing the instructions at line 198

 //This condition fulfills the SVG 1.1 std:
 //the focal point, if outside the end circle, is moved to be on the end circle
 //See: the SVG 2 std requirements: https://www.w3.org/TR/SVG2/pservers.html#RadialGradientNotes
 if (fill->radial.a < 0) {

(lldb) p fill->radial
(SwFill::SwRadial)  (a11 = 0, a12 = 0, a13 = 0, a21 = 0, a22 = 0, a23 = 0, fx = 429, fy = -600, fr = 0, dx = 0, dy = 603, dr = 599.999939, invA = 0, a = -3609.0625)

(lldb) p fill->radial
(SwFill::SwRadial)  (a11 = 0, a12 = 0, a13 = 0, a21 = 0, a22 = 0, a23 = 0, fx = 429, fy = -596.999939, fr = 0, dx = 0, dy = 599.999939, dr = 599.999939, invA = 0, a = 0.0107421838)

[lmdsp]

So it turns out in this case fill->radial.a = fill->radial.dr * fill->radial.dr - fill->radial.dx * fill->radial.dx - fill->radial.dy * fill->radial.dy; at line 204 evaluates to 0 on Intel, but to 0.0107421838 on Apple Silicon !
The correct result is indeed 0 as a=dr²-dx²-dy² with dx=0, dr=dy=599.999939

It seems clang is doing some instruction reordering / FMA which is causing loss of precision.
This happens in both release/debug builds, with options such as GCC_FAST_MATH set to off.

I found that storing intermediary results in temporary variables as shown below fixes the problem:

// Prevent loss of precision on Apple Silicon when dr=dy and dx=0
// https://github.com/thorvg/thorvg/issues/2014
const float dr2 = fill->radial.dr * fill->radial.dr;
const float dx2 = fill->radial.dx * fill->radial.dx;
const float dy2 = fill->radial.dy * fill->radial.dy;

fill->radial.a = dr2 - dx2 - dy2;

@mgrudzinska Do you want me to submit a PR ?

[hermet]

@lmdsp ThorVG welcomes contributors! If you have solutions or improvements, please don't hesitate to submit patches. Thank you for your support!

[hermet]

@lmdsp Your fix will be applied in 0.12.7. Thanks for your contribution