Re: [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

[Philip Race]

Ok. Approved

-phil.

On 2/25/19, 1:42 AM, Dmitry Markov wrote:
That’s right. I ran corresponding regression tests on Ubuntu and I 
didn’t see any issues.


Thanks,
Dmitry

On 23 Feb 2019, at 23:43, Philip Race > wrote:


This doesn't regress anything with the OGL pipeline on Linux, does it ?

-phil.

On 2/18/19, 12:23 AM, Dmitry Markov wrote:

Thank you, Sergey!
Looking for the second +1 from someone else.

Dmitry

On 16 Feb 2019, at 02:10, Sergey Bylokhov 
mailto:sergey.bylok...@oracle.com>> wrote:


Looks fine.

On 15/02/2019 04:06, Dmitry Markov wrote:

Hi Sergey,
I think we can just replace ColorModel based calculation of the 
pixel value with SurfaceData.pixelFor(). The usage of ColorModel 
is intended for old Solaris platforms which are not supported any 
more. Please find the new version 
here:http://cr.openjdk.java.net/~dmarkov/8214109/webrev.01/ 


Also I ran all regression tests and didn’t observe any new failures.
Thanks,
Dmitry
On 31 Jan 2019, at 22:25, Sergey Bylokhov 
> 
wrote:


Hi, Dmitry.
On 30/01/2019 05:02, Dmitry Markov wrote:

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.


But it will be good to move it to java2d code, since this is ogl 
and solaris specific.(if this is really solaris specific then it 
looks like a bug in OGL pipeline)


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.


It is unclear why it is not possible to get this color since the 
current fix has a code to calculate this color.



--
Best regards, Sergey.



--
Best regards, Sergey.

Re: [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

[Dmitry Markov]

That’s right. I ran corresponding regression tests on Ubuntu and I didn’t see 
any issues.

Thanks,
Dmitry

> On 23 Feb 2019, at 23:43, Philip Race  wrote:
> 
> This doesn't regress anything with the OGL pipeline on Linux, does it ?
> 
> -phil.
> 
> On 2/18/19, 12:23 AM, Dmitry Markov wrote:
>> 
>> Thank you, Sergey!
>> Looking for the second +1 from someone else.
>> 
>> Dmitry
>> 
>>> On 16 Feb 2019, at 02:10, Sergey Bylokhov >> > wrote:
>>> 
>>> Looks fine.
>>> 
>>> On 15/02/2019 04:06, Dmitry Markov wrote:
 Hi Sergey,
 I think we can just replace ColorModel based calculation of the pixel 
 value with SurfaceData.pixelFor(). The usage of ColorModel is intended for 
 old Solaris platforms which are not supported any more. Please find the 
 new version here: http://cr.openjdk.java.net/~dmarkov/8214109/webrev.01/ 
 
 Also I ran all regression tests and didn’t observe any new failures.
 Thanks,
 Dmitry
> On 31 Jan 2019, at 22:25, Sergey Bylokhov    >> wrote:
> 
> Hi, Dmitry.
> On 30/01/2019 05:02, Dmitry Markov wrote:
> 
>> 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.
> 
> But it will be good to move it to java2d code, since this is ogl and 
> solaris specific.(if this is really solaris specific then it looks like a 
> bug in OGL pipeline)
> 
>> 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.
> 
> It is unclear why it is not possible to get this color since the current 
> fix has a code to calculate this color.
> 
> 
> -- 
> Best regards, Sergey.
>>> 
>>> 
>>> -- 
>>> Best regards, Sergey.
>>