Re: [OpenJDK 2D-Dev] [9] Review Request 8155753: Removing a monitor in the OS dispaly configuration causes assertion fails under Windows

2016-09-14 Thread Sergey Bylokhov 

On 12.09.16 22:36, Vadim Pakhnushev wrote:

Looks good to me (have you submitted JPRT job just in case?)


+1, I also suggest before the push to check jprt for safety, the change 
are in native + in java on different platforms.




Vadim

On 12/09/16 22:31, Semyon Sadetsky wrote:

 I missed this file in the list of changes.

http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.02/

--Semyon


On 9/12/2016 9:33 PM, Vadim Pakhnushev wrote:

Have you forgotten adding changes in AccelGraphicsConfig?

c:\Vadim\jdk9-client\jdk\src\java.desktop\windows\classes\sun\java2d\d3d\D3DGraphicsConfig.java:52:
error: D3DGraphicsConfig is not abstract and does not override
abstract method removeDeviceEventListener(AccelDeviceEventListener)
in AccelGraphicsConfig
public class D3DGraphicsConfig
   ^
c:\Vadim\jdk9-client\jdk\src\java.desktop\windows\classes\sun\java2d\opengl\WGLGraphicsConfig.java:59:
error: WGLGraphicsConfig is not abstract and does not override
abstract method removeDeviceEventListener(AccelDeviceEventListener)
in AccelGraphicsConfig
public class WGLGraphicsConfig
   ^

Also +#include "Devices.h" in the D3DContext.cpp is a leftover.

Vadim

On 12.09.2016 21:11, Semyon Sadetsky wrote:

http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.01/

AccelDeviceEventNotifier is removed.

--Semyon


On 9/12/2016 6:56 PM, Semyon Sadetsky wrote:

Okay. I will remove AccelDeviceEventNotifier and all related code.

--Semyon


On 9/12/2016 6:43 PM, Vadim Pakhnushev wrote:

Hi Semyon,

Generally seems reasonable, it seems that you should use screen
instead of gdiScreen in the JNU_CallStaticMethodByName, otherwise
the code won't compile.
Not sure how the rest of the code handles monitor removal, seems
to me that there are no usages of this notifications anywhere, so
maybe we don't need this code at all?

Thanks,
Vadim

On 12.09.2016 17:24, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8155753

webrev: http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.00/

The issue take place on Windows platform if Direct3d is on. The
notification routine about the monitor removal tries to get
screen number using the monitor handle which is obviously null at
this moment. As a fix the screen number is recorded in D3D
context for further possible notifications.

--Semyon
















--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [8u Backport] Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees

2016-09-14 Thread Ajit Ghaisas 
Hi Jim,

I agree upon aborting the operation in case the non-finite slope is not due 
to divide by 0 case. 
As this is the 8u backport of the fix done in 9, I will address the review 
comment in JDK-8166009.

The original backport webrev is still the same. 
http://cr.openjdk.java.net/~aghaisas/8158356/8u_backport/webrev.00/

Request you to approve this 8u backport.

Regards,
Ajit

-Original Message-
From: Jim Graham 
Sent: Friday, September 02, 2016 1:16 AM
To: Ajit Ghaisas; Philip Race; 2d-dev
Subject: Re: [8u Backport] Fix for JDK-8158356 : SIGSEGV when attempting to 
rotate BufferedImage using AffineTransform by NaN degrees

Hi Ajit,

In the cases where you "continue" on a non-finite slope, doesn't that mean that 
the edges will be mismatched?  If you can't determine the bounding polygon, 
perhaps the entire operation should be aborted instead...?

It's different from the case of dy1==dy2 which also results in a "continue" 
because in that case there are no edges to insert in the array because that 
edge of the bounding box doesn't occupy any vertical space.  In the case of an 
infinite slope, there could be edges expected to be produced (in fact there 
should be because we've already tested that dy1 != dy2), but the loop doesn't 
produce any edge values and stale data is left in the array.

...jim

On 9/1/16 2:14 AM, Ajit Ghaisas wrote:
> Hi,
>
>
>
>This is a review request for 8u back-port of the fix done in JDK-9.
>
>
>
> Bug :
>
>https://bugs.openjdk.java.net/browse/JDK-8158356
>
>
>
> Root cause :
>
>The root cause of the crash is - NaN is converted to an integer and used 
> as array index in mlib_ImageScanPoly.c.
>
>
>
> Fix :
>
>The native method previously did not check the validity of the 
> input double argument. Now, I have added a check for finite double values.
>
>
>
> Webrev :
>
> 
> http://cr.openjdk.java.net/~aghaisas/8158356/8u_backport/webrev.00/
>
>
>
> Regards,
>
> Ajit
>