The glass code is mis-handling color spaces in numerous places. The most notable is that we don't attach a color space to the CALayer which means the pixels JavaFX produces are interpreted in the default color space of the display (which is probably not sRGB). In other words, users are not seeing the sRGB colors that application authors are specifying.

There are other issues. The Robot code which samples from the display doesn't convert from the display color space to sRGB. The code which sets the window background color interprets the color coming from Java in deviceRGB. The new Platform Preferences API is converting the values to deviceRGB instead of sRGB before passing them into Java.

It looks like the workaround up til now is to force the entire display to default to sRGB so the automated tests don't fail. This isn't necessary and I'm sure end-users aren't doing this which means most are not seeing sRGB colors.

Steps to reproduce:
- Run the attached ColorSpaceTest app
- Bring up the Digital Color Meter which ships with macOS
- Set to "Display in sRGB"
- Use the View > Display Values menu to change to Percentage
- Wave your mouse over the color swatches

Expected results:
The percentages should be clean multiples of 10 (the occasional one might be a percent off and the red channel can get further off out near the edges). This should be true regardless of the display's color profile setting.

Actual results:
On the Studio Display the values are off by multiple points because the pixels provided by JavaFX are being interpreted in the P3 space. Other monitors will exhibit different behavior.