Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG

[Jayathirth D V]

Hi Brian,

 

Thanks for the review.

 

Regards,

Jay

 

From: Brian Burkhalter 
Sent: Friday, September 09, 2016 2:56 AM
To: Philip Race
Cc: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does 
not work when called inside imageStarted for PNG

 

I perused it before and did not notice any problems. Provided all the tests 
still pass I am OK with it.

 

Brian

 

On Sep 8, 2016, at 1:46 PM, Philip Race mailto:philip.r...@oracle.com"philip.r...@oracle.com> wrote:





I wondered what happened to that comment.
I am OK with this so long as Brian is OK with the TIFF changes.

On 8/31/16, 11:55 PM, Jayathirth D V wrote:


@Brian : In case of TIFFImageReader, clearAbortRequest() was not called before 
every read operation, I have added the same. Also I have removed 
processImageProgress(0.0f) call which I feel is not needed as we have 
processImageStarted() which will take care of it(Also to maintain callbacks at 
same intervals as they are in other readers).

 

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Philip Race]

Please consider https://bugs.openjdk.java.net/browse/JDK-8039444
and the various bugs that were closed as a duplicate of that bug.
I don't think you can easily show this fix resolves all of these ..

-phil.


On 9/8/16, 5:12 PM, Semyon Sadetsky wrote:
I have 2 laptops Intel i5, i7. Both working with d3d normally. Some 
visual defects will be corrected after this fix.
And I didn't get why d3d is disabled for all Intel without possibility 
to switch it on?


--Semyon

On 09.09.2016 02:10, Philip Race wrote:
The following is just for testing right ? It should not be in this 
webrev

as part of what you propose to push ..
--
src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h
Print this page

@@ -49,13 +49,10 @@
 // all versions must fail ("there's no version of the driver that 
passes")

 #define NO_VERSION D_VERSION(0x, 0x, 0x, 0x)

 static const ADAPTER_INFO badHardware[] = {

-// All Intel Chips.
-{ 0x8086, ALL_DEVICEIDS, NO_VERSION, OS_ALL },
-
 // ATI Mobility Radeon X1600, X1400, X1450, X1300, X1350
 // Reason: workaround for 6613066, 6687166
 // X1300 (four sub ids)
 { 0x1002, 0x714A, D_VERSION(6,14,10,6706), OS_WINXP },
 { 0x1002, 0x714A, D_VERSION(7,14,10,0567), OS_VISTA },

---

-phil.

On 9/8/16, 4:06 PM, Semyon Sadetsky wrote:

I have reworked fix to not affect ATI and NVidia.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/

--Semyon


On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:



On 08.09.2016 22:57, Philip Race wrote:


Can you provide something like a rationale for why these 
particular values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we 
should defer this.
I suppose those fudge factors are obtained experimentally. Not sure 
that any rationale is possible here.
The fix simply tested on different hardware. I hope after this fix 
D3D maybe enabled again for Intel APUs.

Currently it has been blacklisted in 8039444.

--Semyon


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property 
to do this.


-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that 
one

common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is 
enabled on the intel vk? I recall that d3d was disabled on intel 
so probably to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge 
factors

values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be 
excluded

from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. 
Also I
cannot check the fix on intel card, because I cannot enable 
d3d on it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily 
introduce a

different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: 
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/


The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Semyon Sadetsky]

I have 2 laptops Intel i5, i7. Both working with d3d normally. Some 
visual defects will be corrected after this fix.
And I didn't get why d3d is disabled for all Intel without possibility 
to switch it on?


--Semyon

On 09.09.2016 02:10, Philip Race wrote:

The following is just for testing right ? It should not be in this webrev
as part of what you propose to push ..
--
src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h
Print this page

@@ -49,13 +49,10 @@
 // all versions must fail ("there's no version of the driver that 
passes")

 #define NO_VERSION D_VERSION(0x, 0x, 0x, 0x)

 static const ADAPTER_INFO badHardware[] = {

-// All Intel Chips.
-{ 0x8086, ALL_DEVICEIDS, NO_VERSION, OS_ALL },
-
 // ATI Mobility Radeon X1600, X1400, X1450, X1300, X1350
 // Reason: workaround for 6613066, 6687166
 // X1300 (four sub ids)
 { 0x1002, 0x714A, D_VERSION(6,14,10,6706), OS_WINXP },
 { 0x1002, 0x714A, D_VERSION(7,14,10,0567), OS_VISTA },

---

-phil.

On 9/8/16, 4:06 PM, Semyon Sadetsky wrote:

I have reworked fix to not affect ATI and NVidia.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/

--Semyon


On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:



On 08.09.2016 22:57, Philip Race wrote:


Can you provide something like a rationale for why these particular 
values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we 
should defer this.
I suppose those fudge factors are obtained experimentally. Not sure 
that any rationale is possible here.
The fix simply tested on different hardware. I hope after this fix 
D3D maybe enabled again for Intel APUs.

Currently it has been blacklisted in 8039444.

--Semyon


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to 
do this.


-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is 
enabled on the intel vk? I recall that d3d was disabled on intel 
so probably to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge 
factors

values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be 
excluded

from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable 
d3d on it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily 
introduce a

different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: 
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/


The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Philip Race]

The following is just for testing right ? It should not be in this webrev
as part of what you propose to push ..
--
src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h
Print this page

@@ -49,13 +49,10 @@
 // all versions must fail ("there's no version of the driver that passes")
 #define NO_VERSION D_VERSION(0x, 0x, 0x, 0x)

 static const ADAPTER_INFO badHardware[] = {

-// All Intel Chips.
-{ 0x8086, ALL_DEVICEIDS, NO_VERSION, OS_ALL },
-
 // ATI Mobility Radeon X1600, X1400, X1450, X1300, X1350
 // Reason: workaround for 6613066, 6687166
 // X1300 (four sub ids)
 { 0x1002, 0x714A, D_VERSION(6,14,10,6706), OS_WINXP },
 { 0x1002, 0x714A, D_VERSION(7,14,10,0567), OS_VISTA },

---

-phil.

On 9/8/16, 4:06 PM, Semyon Sadetsky wrote:

I have reworked fix to not affect ATI and NVidia.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/

--Semyon


On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:



On 08.09.2016 22:57, Philip Race wrote:


Can you provide something like a rationale for why these particular 
values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we should 
defer this.
I suppose those fudge factors are obtained experimentally. Not sure 
that any rationale is possible here.
The fix simply tested on different hardware. I hope after this fix 
D3D maybe enabled again for Intel APUs.

Currently it has been blacklisted in 8039444.

--Semyon


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to 
do this.


-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is 
enabled on the intel vk? I recall that d3d was disabled on intel so 
probably to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge 
factors

values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be 
excluded

from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable d3d 
on it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily 
introduce a

different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: 
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/


The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Semyon Sadetsky]

I have reworked fix to not affect ATI and NVidia.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/

--Semyon


On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:



On 08.09.2016 22:57, Philip Race wrote:


Can you provide something like a rationale for why these particular 
values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we should 
defer this.
I suppose those fudge factors are obtained experimentally. Not sure 
that any rationale is possible here.
The fix simply tested on different hardware. I hope after this fix D3D 
maybe enabled again for Intel APUs.

Currently it has been blacklisted in 8039444.

--Semyon


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to 
do this.


-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is enabled 
on the intel vk? I recall that d3d was disabled on intel so probably 
to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge 
factors

values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be excluded
from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable d3d 
on it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily 
introduce a

different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/

The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock.

[Philip Race]

I think the v.1 will be better even if it is not showing up as an issue,
given that you seem to have a safe + simple fix to that part

So "+1" to "1"

-phil.

On 9/8/16, 8:09 AM, Jayathirth D V wrote:

Hi Phil,

More observations:
All emit_message() calls come under macros defined in jerror.h like WARNXX and 
TRACEXX.
I made changes in IJG library so that we call these WARNXX and TRACEXX macros 
forcefully in turn calling emit_message()(emit_message() also changed to call 
output_message() everytime).

With the above change and without RELEASE/GET_ARRAYS change in 
sun_jpeg_output_message() also JVM is not throwing any error. It means when we 
enter sun_jpeg_output_message()  we don't have any active JNI critical lock.

We can actually use http://cr.openjdk.java.net/~jdv/8162461/webrev.00/ without 
RELEASE/GET_ARRAYS change in sun_jpeg_output_message()  or we can use 
http://cr.openjdk.java.net/~jdv/8162461/webrev.01/ having RELEASE/GET_ARRAYS 
change in sun_jpeg_output_message()  for future proofing.

Thanks,
Jay

-Original Message-
From: Jayathirth D V
Sent: Thursday, September 08, 2016 7:21 PM
To: Philip Race; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made 
whilst holding JNI critical lock.

Hi Phil,

Thanks for pointing me to  sun_jpeg_output_message().

We need to make up calls from sun_jpeg_output_message()  as it is needed if 
user has added IIOReadWarningListener.
In imageioJPEG.c we are overriding IJG output_message() of jerror.c with our 
own  sun_jpeg_output_message().

Call from IJG library can reach output_message() through two functions in 
jerror.c :
1) error_exit()
2) emit_message()

We are overriding error_exit() also with sun_jpeg_error_exit() where we are not 
calling output_message(), so sun_jpeg_output_message() can be reached only 
through emit_message() .

emit_message() always takes j_common_ptr as argument and not j_compress_ptr or 
j_decompress_ptr. But I noticed that before calling emit_message() we are 
always type casting j_compress_ptr or j_decompress_ptr to j_common_ptr and 
passing it as argument to emit_message().

Since cinfo->  is_decompressor tells us whether it is read or write operation 
we can cast j_common_ptr to j_compress_ptr or j_decompress_ptr. Based on this I am 
creating jpeg_source_mgr or jpeg_destination_mgr object. Using this we can call 
RELEASE/GET_ARRAYS in sun_jpeg_output_message().

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8162461/webrev.01/

Parallel to this I tried using two separate functions like  
sun_jpeg_reader_output_message(j_decompress_ptr)  and 
sun_jpeg_writer_output_message(j_compress_ptr). But then we need to replicate 
error_exit() and emit_message() also to accept j_decompress_ptr and 
j_compress_ptr. It needs lot of changes at many places where we are using 
error_exit() and emit_message() in IJG library.

Thanks,
Jay

-Original Message-
From: Phil Race
Sent: Wednesday, September 07, 2016 10:57 PM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made 
whilst holding JNI critical lock.

This all looks reasonable. But I wonder if you missed something.
Take a look at sun_jpeg_output_message(). That may also make up-calls.
A pointer to this function is passed to the IJG library and I don't know the 
circumstances under which it may call this function.
If it ever might do it whilst we are holding these locks then that would mean 
we'd need the same RELEASE/GET in there .. although the challenge would be that 
it does not have access to the data to release the arrays.
So
1) Investigate if it is an actual issue,
2) If it is, then decide between a way to ensure the arrays are available to 
this function (looks tricky to me), or somehow deferring these up-calls or 
eliminating them.

-phil.

On 9/6/2016 11:49 PM, Jayathirth D V wrote:

Fixed typo.

*From:* Jayathirth D V
*Sent:* Wednesday, September 07, 2016 12:11 PM
*To:* Philip Race; 2d-dev
*Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI
up-call made whilst holding JNI critical lock.

Hi,

Please review the following fix in JDK9 at your convenience:

Bug : https://bugs.openjdk.java.net/browse/JDK-8162461

Webrev : http://cr.openjdk.java.net/~jdv/8162461/webrev.00/


Issue : If we try to perform operations like
reader.abort()/reader.dispose()/ reader.reset() in any of the
IIOReadUpdateListener callbacks, JVM will throw deadlock error.

Root cause : We are making callbacks from native side to Java by
holding some resources in JNI critical lock.

Solution : We have to release the JNI critical lock on the resources
before we call Java function from native side. If we have JNI critical
lock and we throw an Exception in that case also we should release the
lock.

Thanks,

Jay

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Semyon Sadetsky]

On 08.09.2016 22:57, Philip Race wrote:


Can you provide something like a rationale for why these particular 
values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we should 
defer this.
I suppose those fudge factors are obtained experimentally. Not sure that 
any rationale is possible here.
The fix simply tested on different hardware. I hope after this fix D3D 
maybe enabled again for Intel APUs.

Currently it has been blacklisted in 8039444.

--Semyon


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to do 
this.


-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is enabled 
on the intel vk? I recall that d3d was disabled on intel so probably 
to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge factors
values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be excluded
from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable d3d 
on it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily introduce a
different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/

The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG

[Brian Burkhalter]

I perused it before and did not notice any problems. Provided all the tests 
still pass I am OK with it.

Brian

On Sep 8, 2016, at 1:46 PM, Philip Race  wrote:

> I wondered what happened to that comment.
> I am OK with this so long as Brian is OK with the TIFF changes.
> 
> On 8/31/16, 11:55 PM, Jayathirth D V wrote:
>> 
>> 
>> @Brian : In case of TIFFImageReader, clearAbortRequest() was not called 
>> before every read operation, I have added the same. Also I have removed 
>> processImageProgress(0.0f) call which I feel is not needed as we have 
>> processImageStarted() which will take care of it(Also to maintain callbacks 
>> at same intervals as they are in other readers).

Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does not work when called inside imageStarted for PNG

[Philip Race]

I wondered what happened to that comment.
I am OK with this so long as Brian is OK with the TIFF changes.

-phil.

On 8/31/16, 11:55 PM, Jayathirth D V wrote:

Hi Phil&  Brian,

Before this code change there was no check for abortRequested() right after 
processImagestarted() callback in GIFImageReader.java.
After code change we are checking for abortRequested() right after 
processImagestarted(). So after this call there is no need to verify for 
abortRequested() before processImageProgress() so I have moved the logic from 
while(abortRequested()) { ... } to do {...} while(abortRequested()). I have 
just removed redundant check for abortRequested().

Also as discussed offline I have made small change in JPEGImageReader.java to remove 
initialization of "boolean aborted" variable which is not used.
Also I noticed that previously I was overriding comment present in same file 
with new comment , I have corrected that mistake.
Please find updated webrev with the changes in JPEGImageReader.java:
http://cr.openjdk.java.net/~jdv/4924727/webrev.03/

@Brian : In case of TIFFImageReader, clearAbortRequest() was not called before 
every read operation, I have added the same. Also I have removed 
processImageProgress(0.0f) call which I feel is not needed as we have 
processImageStarted() which will take care of it(Also to maintain callbacks at 
same intervals as they are in other readers).

Thanks,
Jay

-Original Message-
From: Philip Race
Sent: Thursday, September 01, 2016 4:48 AM
To: Sergey Bylokhov
Cc: Jayathirth D V; 2d-dev; brian Burkhalter
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort() method does 
not work when called inside imageStarted for PNG

I don't understand why the change from while() { .. } to do { .. }
while(..) was
needed in GIFImageReader but then I don't see any harm in it either.
Can you explain that one ?

Also I'd like Brian to sign off on the TIFF change.

Other than that all seems fine.

-phil.

On 8/31/16, 5:37 AM, Sergey Bylokhov wrote:

On 31.08.16 14:48, Jayathirth D V wrote:

Hi Sergey,

In case of JPEG whole read process is under a ThreadLock.
 public BufferedImage read(int imageIndex, ImageReadParam param)
 throws IOException {
 setThreadLock();
 try {
 cbLock.check();
 try {
 readInternal(imageIndex, param, false);

Then the fix looks fine.


By others processXXX() do you mean processXXX() in other plugins or
processXXX() in case of JPEG?
Please clarify.

I meant only the code related to jpeg.


Thanks,
Jay

-Original Message-
From: Sergey Bylokhov
Sent: Wednesday, August 31, 2016 4:22 PM
To: Jayathirth D V; Philip Race
Cc: 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort()
method does not work when called inside imageStarted for PNG

I have only one question: should we call the new
clearNativeReadAbortFlag(and probably the others processXXX()) under
the ThreadLock?

On 31.08.16 13:07, Jayathirth D V wrote:

Hi Sergey,

Thanks for the clarification.
I have updated the test case to use Files.delete().
Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/4924727/webrev.02/

Regards,
Jay

-Original Message-
From: Sergey Bylokhov
Sent: Monday, August 29, 2016 8:52 PM
To: Jayathirth D V
Cc: 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort()
method does not work when called inside imageStarted for PNG

On 29.08.16 18:07, Jayathirth D V wrote:

Hi Sergey,

I am not getting the usage of Files.delete() from its
specification. Can you please elaborate what special case it will
handle in my test case?
I am creating temporary file separately for all the readers and
deleting them.

Files.delete() will throw an exception if the file cannot be
deleted, and File.delete() will return false in such case.

Also I am closing the ImageInputStream associated after read operation.

But plugin itself can leak some streams and lock a temporary file,
so
Files.delete() will catch this.



-Original Message-
From: Sergey Bylokhov
Sent: Monday, August 29, 2016 8:25 PM
To: Jayathirth D V; Philip Race
Cc: Prasanta Sadhukhan; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-4924727 : reader.abort()
method does not work when called inside imageStarted for PNG

Hi, Jay.
Please delete the temporary file via Files.delete(), which will
throw an exception if the file is locked by some reader.

On 29.08.16 11:42, Jayathirth D V wrote:

Hi Phil&  Sergey,

Thanks for your inputs.

I have verified reader.abort() request for IIOReadProgressListener
for all available plugins.

Apart from PNG although all readers were able to abort read when
we call reader.abort() from IIOReadProgressListener callbacks,
they were not calling processReadAborted() right after
IIOReadProgressListener callbacks. So I have made changes for the
same.

And in some readers before every read call they were not calling
clearAbortRequest(), which is important because if we u

Re: [OpenJDK 2D-Dev] RFR: 8162531solaris.fontconfig.properties needs updating

[Philip Race]

[Fix i18n-dev address]

-phil.

On 9/8/16, 1:10 PM, Philip Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
Webrev: http://cr.openjdk.java.net/~prr/8162531/

Solaris 10 is not supported by JDK 9.
This updates the fontconfig file to focus on the default set of fonts
installed on Solaris 11 as part its desktop.

Preference is given to the Arial, Times New Roman, and Courier New fonts
that are included with Solaris, as well as other monotype fonts.
Dejavau Sans is listed for some fallback coverage of less commonly used
unicode blocks.

10646-1 encoding is referenced so as to reduce the number of entries.
More UTF 8 locales were added since that is the default on Solaris 11.

-phil.

[OpenJDK 2D-Dev] RFR: 8162531solaris.fontconfig.properties needs updating

[Philip Race]

Bug: https://bugs.openjdk.java.net/browse/JDK-8162531
Webrev: http://cr.openjdk.java.net/~prr/8162531/

Solaris 10 is not supported by JDK 9.
This updates the fontconfig file to focus on the default set of fonts
installed on Solaris 11 as part its desktop.

Preference is given to the Arial, Times New Roman, and Courier New fonts
that are included with Solaris, as well as other monotype fonts.
Dejavau Sans is listed for some fallback coverage of less commonly used
unicode blocks.

10646-1 encoding is referenced so as to reduce the number of entries.
More UTF 8 locales were added since that is the default on Solaris 11.

-phil.

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Philip Race]

Can you provide something like a rationale for why these particular 
values might work ?

Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we should 
defer this.


IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to do this.

-phil.

On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is enabled 
on the intel vk? I recall that d3d was disabled on intel so probably 
to check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge factors
values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be excluded
from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable d3d on 
it.




--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified 
hardware-dependent

territory but
it seems quite possible that this could just as easily introduce a
different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to 
include at

least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/

The root cause is incorrect coordinate rounding in D3D 
renderer. To

fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock.

[Jayathirth D V]

Hi Phil,

More observations:
All emit_message() calls come under macros defined in jerror.h like WARNXX and 
TRACEXX.
I made changes in IJG library so that we call these WARNXX and TRACEXX macros 
forcefully in turn calling emit_message()(emit_message() also changed to call 
output_message() everytime).

With the above change and without RELEASE/GET_ARRAYS change in 
sun_jpeg_output_message() also JVM is not throwing any error. It means when we 
enter sun_jpeg_output_message()  we don't have any active JNI critical lock. 

We can actually use http://cr.openjdk.java.net/~jdv/8162461/webrev.00/ without 
RELEASE/GET_ARRAYS change in sun_jpeg_output_message()  or we can use 
http://cr.openjdk.java.net/~jdv/8162461/webrev.01/ having RELEASE/GET_ARRAYS 
change in sun_jpeg_output_message()  for future proofing.

Thanks,
Jay

-Original Message-
From: Jayathirth D V 
Sent: Thursday, September 08, 2016 7:21 PM
To: Philip Race; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made 
whilst holding JNI critical lock.

Hi Phil,

Thanks for pointing me to  sun_jpeg_output_message().

We need to make up calls from sun_jpeg_output_message()  as it is needed if 
user has added IIOReadWarningListener.
In imageioJPEG.c we are overriding IJG output_message() of jerror.c with our 
own  sun_jpeg_output_message().

Call from IJG library can reach output_message() through two functions in 
jerror.c :
1) error_exit()
2) emit_message()

We are overriding error_exit() also with sun_jpeg_error_exit() where we are not 
calling output_message(), so sun_jpeg_output_message() can be reached only 
through emit_message() .

emit_message() always takes j_common_ptr as argument and not j_compress_ptr or 
j_decompress_ptr. But I noticed that before calling emit_message() we are 
always type casting j_compress_ptr or j_decompress_ptr to j_common_ptr and 
passing it as argument to emit_message().

Since cinfo-> is_decompressor tells us whether it is read or write operation we 
can cast j_common_ptr to j_compress_ptr or j_decompress_ptr. Based on this I am 
creating jpeg_source_mgr or jpeg_destination_mgr object. Using this we can call 
RELEASE/GET_ARRAYS in sun_jpeg_output_message().

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8162461/webrev.01/

Parallel to this I tried using two separate functions like  
sun_jpeg_reader_output_message(j_decompress_ptr)  and 
sun_jpeg_writer_output_message(j_compress_ptr). But then we need to replicate 
error_exit() and emit_message() also to accept j_decompress_ptr and 
j_compress_ptr. It needs lot of changes at many places where we are using 
error_exit() and emit_message() in IJG library.

Thanks,
Jay

-Original Message-
From: Phil Race
Sent: Wednesday, September 07, 2016 10:57 PM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made 
whilst holding JNI critical lock.

This all looks reasonable. But I wonder if you missed something.
Take a look at sun_jpeg_output_message(). That may also make up-calls.
A pointer to this function is passed to the IJG library and I don't know the 
circumstances under which it may call this function.
If it ever might do it whilst we are holding these locks then that would mean 
we'd need the same RELEASE/GET in there .. although the challenge would be that 
it does not have access to the data to release the arrays.
So
1) Investigate if it is an actual issue,
2) If it is, then decide between a way to ensure the arrays are available to 
this function (looks tricky to me), or somehow deferring these up-calls or 
eliminating them.

-phil.

On 9/6/2016 11:49 PM, Jayathirth D V wrote:
>
> Fixed typo.
>
> *From:* Jayathirth D V
> *Sent:* Wednesday, September 07, 2016 12:11 PM
> *To:* Philip Race; 2d-dev
> *Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI 
> up-call made whilst holding JNI critical lock.
>
> Hi,
>
> Please review the following fix in JDK9 at your convenience:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8162461
>
> Webrev : http://cr.openjdk.java.net/~jdv/8162461/webrev.00/
> 
>
> Issue : If we try to perform operations like 
> reader.abort()/reader.dispose()/ reader.reset() in any of the 
> IIOReadUpdateListener callbacks, JVM will throw deadlock error.
>
> Root cause : We are making callbacks from native side to Java by 
> holding some resources in JNI critical lock.
>
> Solution : We have to release the JNI critical lock on the resources 
> before we call Java function from native side. If we have JNI critical 
> lock and we throw an Exception in that case also we should release the 
> lock.
>
> Thanks,
>
> Jay
>

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock.

[Jayathirth D V]

Hi Phil,

Thanks for pointing me to  sun_jpeg_output_message().

We need to make up calls from sun_jpeg_output_message()  as it is needed if 
user has added IIOReadWarningListener.
In imageioJPEG.c we are overriding IJG output_message() of jerror.c with our 
own  sun_jpeg_output_message().

Call from IJG library can reach output_message() through two functions in 
jerror.c :
1) error_exit()
2) emit_message()

We are overriding error_exit() also with sun_jpeg_error_exit() where we are not 
calling output_message(), so sun_jpeg_output_message() can be reached only 
through emit_message() .

emit_message() always takes j_common_ptr as argument and not j_compress_ptr or 
j_decompress_ptr. But I noticed that before calling emit_message() we are 
always type casting j_compress_ptr or j_decompress_ptr to j_common_ptr and 
passing it as argument to emit_message().

Since cinfo-> is_decompressor tells us whether it is read or write operation we 
can cast j_common_ptr to j_compress_ptr or j_decompress_ptr. Based on this I am 
creating jpeg_source_mgr or jpeg_destination_mgr object. Using this we can call 
RELEASE/GET_ARRAYS in sun_jpeg_output_message().

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8162461/webrev.01/

Parallel to this I tried using two separate functions like  
sun_jpeg_reader_output_message(j_decompress_ptr)  and 
sun_jpeg_writer_output_message(j_compress_ptr). But then we need to replicate 
error_exit() and emit_message() also to accept j_decompress_ptr and 
j_compress_ptr. It needs lot of changes at many places where we are using 
error_exit() and emit_message() in IJG library.

Thanks,
Jay

-Original Message-
From: Phil Race 
Sent: Wednesday, September 07, 2016 10:57 PM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI up-call made 
whilst holding JNI critical lock.

This all looks reasonable. But I wonder if you missed something.
Take a look at sun_jpeg_output_message(). That may also make up-calls.
A pointer to this function is passed to the IJG library and I don't know the 
circumstances under which it may call this function.
If it ever might do it whilst we are holding these locks then that would mean 
we'd need the same RELEASE/GET in there .. although the challenge would be that 
it does not have access to the data to release the arrays.
So
1) Investigate if it is an actual issue,
2) If it is, then decide between a way to ensure the arrays are available to 
this function (looks tricky to me), or somehow deferring these up-calls or 
eliminating them.

-phil.

On 9/6/2016 11:49 PM, Jayathirth D V wrote:
>
> Fixed typo.
>
> *From:* Jayathirth D V
> *Sent:* Wednesday, September 07, 2016 12:11 PM
> *To:* Philip Race; 2d-dev
> *Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI 
> up-call made whilst holding JNI critical lock.
>
> Hi,
>
> Please review the following fix in JDK9 at your convenience:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8162461
>
> Webrev : http://cr.openjdk.java.net/~jdv/8162461/webrev.00/
> 
>
> Issue : If we try to perform operations like 
> reader.abort()/reader.dispose()/ reader.reset() in any of the 
> IIOReadUpdateListener callbacks, JVM will throw deadlock error.
>
> Root cause : We are making callbacks from native side to Java by 
> holding some resources in JNI critical lock.
>
> Solution : We have to release the JNI critical lock on the resources 
> before we call Java function from native side. If we have JNI critical 
> lock and we throw an Exception in that case also we should release the 
> lock.
>
> Thanks,
>
> Jay
>

Re: [OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

[Sergey Bylokhov]

On 05.09.16 13:36, Semyon Sadetsky wrote:

At last I could get NVidia machine (special thanks to Yuri).

The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.

http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/


Can you please confirm that the fix and test works if d3d is enabled on 
the intel vk? I recall that d3d was disabled on intel so probably to 
check that we need to force d3d manually.



On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:

Hi Phil,

Sergey wrote it fails on nvidia cards. I could play with fudge factors
values but I don't have nvidia based video to test.

--Semyon

On 3/17/2016 11:05 PM, Phil Race wrote:

Semyon,

Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.

-phil.


On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:

On 15.01.16 9:59, Semyon Sadetsky wrote:

Hi Phil & Sergey,

I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel image but the scaled one. So Mac platform should be excluded
from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/


I run the latest test(webrev.03) on my nvidia card, and it fails
after the fix, but pass before =(. I have no ati to check. Also I
cannot check the fix on intel card, because I cannot enable d3d on it.



--Semyon

On 1/14/2016 9:23 PM, Phil Race wrote:

This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments
seem to
indicate that
there was a fair amount of testing on different hardware.

I don't know why this seems to be in un-specified hardware-dependent
territory but
it seems quite possible that this could just as easily introduce a
different artifact
on some other hardware.

What exactly are you testing on ? And I think it needs to include at
least one Nvidia
and one AMD/ATI card.

-phil.

On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:

Hello,

Please review the fix for jdk9.

bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/

The root cause is incorrect coordinate rounding in D3D renderer. To
fix the issue one of fudge factors was adjusted.

Another issue mentioning in the JIRA ticket is taken out as a
separate bug.

--Semyon

















--
Best regards, Sergey.