[OpenJDK 2D-Dev] Review request for JDK-7182758: BMPMetadata returns invalid PhysicalPixelSpacing

2015-10-12 Thread Jayathirth D V 
Hello All,

 

Made small change on how we need to represent floating point constant in 
Java(1000.0 -> 1000.0F).

 

Please find updated Webrev link:

 

Webrev : http://cr.openjdk.java.net/~rchamyal/jay/7182758/webrev.01/

 

Please review.

 

Thanks,

Jay

 

 

From: Jayathirth D V 
Sent: Thursday, October 08, 2015 2:20 PM
To: 2d-dev@openjdk.java.net; Philip Race; Sergey Bylokhov
Subject: [OpenJDK 2D-Dev]  Review request for JDK-7182758: 
BMPMetadata returns invalid PhysicalPixelSpacing

 

Hello All,

 

Please review following fix in jdk9:

 

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

 

Webrev : http://cr.openjdk.java.net/~rchamyal/jay/7182758/webrev.00/

 

Bug : BMPMetadata returns invalid PhysicalPixelSpacing

 

Root cause : Whenever XPixelsPerMter or YPixelsPerMeter is more than value 1 in 
BMP header. Horizontal & Vertical Physical pixel spacing were returned as zero.

  In getStandardDimensionNode() method of 
BMPMetadata.java we are dividing 1 by XPixelsPerMter/ YPixelsPerMter. When

  XPixelsPerMter/ YPixelsPerMter is more than 1. 
Resulted value is stored without decimal part, which resulted in zero.

 

Solution : Made changes to how Horizontal & Vertical Physical pixel spacing is 
calculated so that decimal value is not truncated.

 

Thanks,

Jay

[OpenJDK 2D-Dev] [9] Review request for 8130136: Swing window sometimes fails to repaint partially when it becomes exposed

2015-10-12 Thread Alexey Ivanov 

Hello,

Please review the fix for jdk9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130136
webrev: http://cr.openjdk.java.net/~aivanov/8130136/jdk9/webrev.00/


Problem description:
Sometimes a window fails to repaint when it becomes exposed.

When repaint failure occurs, SetDIBitsToDevice() in 
GDIBlitLoops_nativeBlit() returns 0 with error 87 ("Parameter Error"). 
It happens because invalid, already released, hDC is passed to 
SetDIBitsToDevice().



Root cause:
When a window is disposed, the DCs associated with it are released. The 
handles can be reused for another window.


A thread disposes the window and releases hDC. At this time, DC handle 
is reused for another window. When Disposer thread cleans up for a died 
thread, it tries to release the cached hDC. But that handle is already 
associated with another window. Thus a valid pair hWnd/hDC becomes 
invalid: painting to released DC fails.



The fix:
Save both hDC and hWnd in the thread local storage, and pair hDC with 
hWnd when removing it to avoid accidentally releasing hDC which is 
already reused for another window.



Regards,
Alexey

Re: [OpenJDK 2D-Dev] [9] Review request for 8130136: Swing window sometimes fails to repaint partially when it becomes exposed

2015-10-12 Thread Alexander Potochkin 

Hello Alexey

The fix looks reasonable.
However the javadoc for RemoveDC method should be updated.
Could you please describe the new logic there?

When does the GetHWnd() method return zero?
Do we need to check it in RemoveDC?

I guess you didn't add the test for a good reason,
could you please comment on that?

Thanks
alexp

On 10/12/2015 12:11, Alexey Ivanov wrote:

Hello,

Please review the fix for jdk9:
bug: https://bugs.openjdk.java.net/browse/JDK-8130136
webrev: http://cr.openjdk.java.net/~aivanov/8130136/jdk9/webrev.00/


Problem description:
Sometimes a window fails to repaint when it becomes exposed.

When repaint failure occurs, SetDIBitsToDevice() in 
GDIBlitLoops_nativeBlit() returns 0 with error 87 ("Parameter Error"). 
It happens because invalid, already released, hDC is passed to 
SetDIBitsToDevice().



Root cause:
When a window is disposed, the DCs associated with it are released. 
The handles can be reused for another window.


A thread disposes the window and releases hDC. At this time, DC handle 
is reused for another window. When Disposer thread cleans up for a 
died thread, it tries to release the cached hDC. But that handle is 
already associated with another window. Thus a valid pair hWnd/hDC 
becomes invalid: painting to released DC fails.



The fix:
Save both hDC and hWnd in the thread local storage, and pair hDC with 
hWnd when removing it to avoid accidentally releasing hDC which is 
already reused for another window.



Regards,
Alexey

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information

2015-10-12 Thread Jim Graham 

Looks good!

...jim

On 10/11/15 10:59 PM, prasanta sadhukhan wrote:

Thanks for the review.
I have removed the unused fields.
Here's the modified webrev:
http://cr.openjdk.java.net/~psadhukhan/8072682/webrev.01/

Hi Sergey, can you commit this fix?

Regards
Prasanta
On 10/10/2015 2:02 AM, Jim Graham wrote:

+1 for the fix and removing the fields.

...jim

On 10/9/15 8:37 AM, Sergey Bylokhov wrote:

Hi, Prasanta.
It seems that width&height fields are not used after the fix and can be
removed.

On 08.10.15 11:12, prasanta sadhukhan wrote:

Hi All,

Please review a fix for jdk9

Bug: https://bugs.openjdk.java.net/browse/JDK-8072682
webrev: http://cr.openjdk.java.net/~psadhukhan/8072682/webrev.00/

BufferedImageGraphicsConfig creates a cache to store the BufferedImage
information but it was found that the cache shares the
GraphicsConfiguration across images of the same type,
so for different images of same type, the first stored information is
returned when getBounds() is queried.
The consensus is instead of adding image bounds info to the cache, let
the deviceConfig.getBounds() returns the MAXINT bounds.

Regards
Prasanta