<AWT Dev> [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

[Dmitry Markov]

Hi Sergey,

I understand your intention to get rid of “the check of the current 2d pipeline” but it appears impossible to move the related code to java2d in particular OGL. 
Currently OGL uses ArgbPre pixel converter for rendering. Default pixel converter is used for calculation of pixel value when background colour is set because ArgbPre does not return the correct value for OGL on Solaris (according to JDK-6304250). 
I do not see any way to distinguish between setting of background colour and other rendering operations from java2d code. 

Thanks,
Dmitry

> On 29 Jan 2019, at 06:32, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Dmitry.
> 
> It looks like the whole fix is a rework of JDK-6304250, so
> probably it is possible to fix it in java2d(in ogl) and
> eliminate this "check for the current 2d pipeline" from the awt code?
> 
> It is looks strange that in OGL we can use correct color in "repain()"
> and cannot get this color in other place.
> 
> On 27/01/2019 06:26, Dmitry Markov wrote:
>> Hello,
>> Could you review a fix for jdk13, please?
>> bug: https://bugs.openjdk.java.net/browse/JDK-8214109
>> webrev: http://cr.openjdk.java.net/~dmarkov/8214109/webrev.00/
>> Problem description:
>> On xvnc4 environment the colour of the background and the colour of the repaint area may be different (and it’s visually noticeable) even if the same colour is specified. The root cause of this behaviour is that we always use ColorModel to calculate a pixel value in XWindow.xSetBackground() and at the same time the pixel value for repaint area is calculated using SurfaceData methods, (e.g. SurfaceData.pixelFor()). Actually this is regression caused by JDK-6304250 which introduced ColorModel based calculation of the pixel value to fix problem for OpenGL pipeline.
>> Fix:
>> It is necessary to modify XWindow.xSetBackground(): if OpenGL pipeline is enabled we should use ColorModel to calculate the pixel value; otherwise we should use SurfaceData.pixelFor() for calculation.
>> Thanks,
>> Dmitry
> 
> 
> -- 
> Best regards, Sergey.