#2813 transparent color rendering error using "with pm3d fc ls N" on ARM-based Mac
This bug occurs specifically on macOS running on ARM architecture.
Here is a test script that demonstrates the issue:
unset key
unset colorbox
set samples 20
set isosamples 20
set xyplane relative 0
set xrange [ -3.00 : 3.00 ]
set yrange [ -3.00 : 3.00 ]
set zrange [ -2.00 : 1.00 ]
set pm3d depthorder border lc "gray"
set style line 3 lc rgb "#8000ff00"
set style line 4 lc rgb "#7fff0000"
splot -1/(x**2+y**2) with pm3d fc ls 3
When executed, this script should draw a semi-transparent surface: the top face filled with green and the bottom face with red. However, on ARM-based Mac, the top face is incorrectly rendered as opaque black, as shown in the attached image. This issue arises from differences in behavior between ARM and x86 (x64) architectures.
In the implementation of "with pm3d fc ls N", the color information (stored as a 32-bit signed integer in the linestyle) is retrieved as follows: It is first cast to a double, and then back to a 32-bit unsigned int during processing. For example, the color #8000ff00 specified in linestyle 3 in the script is stored as -2147418368 (32-bit signed int). Casting this to double gives -2147418368.0, and casting that to a 32-bit unsigned int should result in 2147548928 (0x8000ff00), which represents a semi-transparent green. However, on ARM systems, casting a negative double -2147418368.0 to a 32-bit unsigned int yields 0, resulting in the default rendering color of opaque black.
This behavior is consistent with known ARM-specific differences in type casting semantics. For further detail, see the section “Conversion of floating-point to unsigned integer” in Microsoft’s documentation on Common Visual C++ ARM migration issues.
The attached patch provides a workaround for this issue.
Got it. Thanks.