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

[Jayathirth D V]

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() 

Re: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test java/awt/font/TextLayout/VisibleAdvance.java fails

[Steven Loomis]

This one also looks good to me.

- Original Message -
From: prasanta.sadhuk...@oracle.com
To: philip.r...@oracle.com, 2d-dev@openjdk.java.net
Sent: Tuesday, August 30, 2016 11:55:43 PM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenJDK 2D-Dev] RFR: 8164818: Reg. test 
java/awt/font/TextLayout/VisibleAdvance.java fails

Looks good to me.

Regards
Prasanta
On 8/26/2016 4:46 AM, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8164818
> webrev: http://cr.openjdk.java.net/~prr/8164818/
>
> 26.6 fixed point was being used in harfbuzz interface code
> and 16.16 elsewhere so we had a precision mismatch.
> More details in the bug report.
>
> -phil.

Re: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests

[Steven Loomis]

Looks good to me!

- Original Message -
From: prasanta.sadhuk...@oracle.com
To: philip.r...@oracle.com, 2d-dev@openjdk.java.net
Sent: Wednesday, August 31, 2016 3:17:27 AM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font 
tests

Looks ok to me.

Regards
Prasanta
On 8/26/2016 2:40 AM, Phil Race wrote:
>
> Webrev: http://cr.openjdk.java.net/~prr/8144015/
>
> This RFR encompasses changes that are sufficiently related
> to keep them all together and they deserve testing as a whole.
> Multiple test failures are resolved. A list is below.
>
> Notable highlights
> ExtendedTextSourceLabel.createCharinfo() can now handle
> cases where the glyph count is less than the char count.
> This was not just a problem in 9 (harfbuzz) but has been
> observed on 8 too (8041480 in the list below).
> The fundamental change is to abandon the idea of
> updating in place which added complexity and was
> never going to work if you had too few glyphs ..
>
> HBShaper.c
> - Fixed that kerning was always enabled
> - Simplified - and corrected - the code that stored the resulting data
> - Stopped using throwing an exception as a way to expand storage
> - Cleaned up JNI usage
>
> Tests have been added/updated/open sourced as necessary.
>
> JPRT passed these changes.
>
>
> Bugs fixed by this change :
> https://bugs.openjdk.java.net/browse/JDK-8144015
> 8144015: [PIT] failures of text layout font tests
>
> ** https://bugs.openjdk.java.net/browse/JDK-8144023
> 8144023: [PIT] failure of text measurements in 
> javax/swing/text/html/parser/Parser/6836089/bug6836089.java
>
> ** https://bugs.openjdk.java.net/browse/JDK-8145542
> 8145542: The case failed automatically and thrown 
> java.lang.ArrayIndexOutOfBoundsException exception
>
> ** https://bugs.openjdk.java.net/browse/JDK-8151725
> 8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari 
> text in JEditorPane
>
> ** https://bugs.openjdk.java.net/browse/JDK-8144240
> 8144240: [macosx][PIT] AIOOB in 
> closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java
>
> https://bugs.openjdk.java.net/browse/JDK-8152680
> 8152680: Regression in GlyphVector.getGlyphCharIndex behaviour
>
> ** https://bugs.openjdk.java.net/browse/JDK-8158924
> 8158924: Incorrect i18n text document layout
>
> ** https://bugs.openjdk.java.net/browse/JDK-8041480
> 8041480: ArrayIndexOutOfBoundsException when JTable contains certain 
> string
>
> -phil.

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

[Philip Race]

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 use same 
reader for another read() call it will be invalid unless we clear 
previous abort request.


In case of JPEG since we are using native IJG library we need to 
update abortFlag present in imageioJPEG.c before every call as we 
are doing for other readers using clearAbortRequest().


Since this has native and make changes I have verified changes
through JPRT also which is successfully building on all platforms
(http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay. 


client_commit//JobStatus.txt )

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

I noticed that in case on WBMP I was not getting ImageReader 
object to call setInput() in test case to verify the behavior of 
reader.abort(). So I have created separate bug for the same 
(https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case 
of WBMP we already have clearAbortRequest() call and also we are 
returning from IIOReadProgressListener callbacks properly, only 
thing here is we are not returning right after callbacks as we 
have updated other plugins.


I want to verify writer plugins in separate bug as we already have 
lot of changes in this bug. So I have created 
https://bugs.openjdk.java.net/browse/JDK-8164931 and will be 
working on this bug.


Thanks,
Jay

-Original Message-
From: Phil Race
Sent: Thursday, August 18, 2016 1:42 AM
To: Sergey Bylokhov
Cc: Jayathirth D V; 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

I think we can
- get all plugins,and for each
- write a file in that format
- read it ba

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8160327: Support for thumbnails present in APP1 marker for JPEG

[Philip Race]

imageCreationTime = LocalDateTime.parse(dateTime, formatter);

Seems like it may throw DateTimeParseException - a subtype of 
RuntimeException

https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#parse-java.lang.CharSequence-java.time.format.DateTimeFormatter-

I think in the case of such malformed data we want to silently swallow it
rather than propagate to the caller.

 164 // XXX Might want to set 
JPEGImageReader$ThumbnailReadListener

 165 // to track thumbnail reading progress.

XXX ?

int getThumbnailWidth(int index) {
 187 if (getNumThumbnails() != 1 || index != 0) {
 188 throw new IndexOutOfBoundsException();
 189 }
 190 return thumbnailWidth;
 191 }

Would it not be more informative to include "index" in the exception ?

Other than that looks fine.

-phil.

On 8/29/16, 7:39 AM, Brian Burkhalter wrote:

Please review at your convenience.

Issue:  https://bugs.openjdk.java.net/browse/JDK-8160327
Patch:  http://cr.openjdk.java.net/~bpb/8160327/webrev.00/

Add thumbnail and standard metadata Document/ImageCreationTime from the APP1 
Exif marker segment if present

The code has been tested using JPEG-Exif images with compressed thumbnails from 
Canon, Nikon, and Olympus cameras, and using a JPEG-Exif image with an 
uncompressed thumbnail from a Sony camera.

Thanks,

Brian

Re: [OpenJDK 2D-Dev] [9] RFR 8165146 [PIT][TEST_BUG] Doubtful usability of java/awt/print/PrinterJob/TestMediaTraySelection.java

[Phil Race]

+1

-phil.

On 8/31/2016 9:58 AM, Prasanta Sadhukhan wrote:

Hi All,

It seems there is a question mark on the usability of the testcase if 
the user does not have a printer that does not have multiple trays.
The testcase might be useful for dev environment so removing @test tag 
to prevent it running from jtreg harness.

Please review.

 hg diff test/java/awt/print/PrinterJob/TestMediaTraySelection.java
diff -r 145d979bb1fb 
test/java/awt/print/PrinterJob/TestMediaTraySelection.java
--- a/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Tue 
Aug 30 11:07:58 2016 +0530
+++ b/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Wed 
Aug 31 22:25:53 2016 +0530

@@ -21,8 +21,7 @@
  * questions.
  */
 /*
- * @test
- * @bug 6357887
+ * @bug 6357887 8165146
  * @summary  Verifies if selected printertray is used

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [9] RFR JDK-7064425: PageFormat Dialog has no owner window to reactivate

[Phil Race]

 911 public boolean printDialog(final PrintRequestAttributeSet attributes)
...
 956 attributes.add(new DialogOwner((Frame)w));

So this now adds the DialogOwner to the attribute set passed by the application.

This needs to be guaranteed to be removed again before the method returns 
otherwise
apart from leaving that visible to the application, there is some risk that the
frame will not be GC'd when it should have been.


-Frame ownerFrame = (dlgOwner != null) ? dlgOwner.getOwner() : null;
+Window ownerFrame = (dlgOwner != null) ? dlgOwner.getOwner() : null

so maybe change the var name to just "owner" ?

WPrintDialog dialog;
 484 if (ownerFrame instanceof Frame) {
 485 dialog = new WPrintDialog((Frame)ownerFrame, this);
 486 } else {
 487 dialog = new WPrintDialog((Dialog)ownerFrame, this);
 488 }

could (should?) be


WPrintDialog dialog =
  new WPrintDialog(((owner instanceof Frame)  ? (Frame)owner : 
(Dialog)owner), this)

and so on for the other cases too .. it will save a lot
of repetition for newPrintToFileErrorDialog(..)

-phil.


On 08/26/2016 01:05 AM, Prasanta Sadhukhan wrote:

Hi All,

I have modified the webrev to take care of JDK-6948907 
: 
sun.print.DialogOwner does not support Dialogs as DialogOwner

also.
http://cr.openjdk.java.net/~psadhukhan/7064425/webrev.01/

Tested on windows and ubuntu.

Regards
Prasanta
On 8/25/2016 4:10 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for jdk9 for an issue where it is seen that 
PageDialog and PrintDialog is not associated with the owner Frame 
that spawns the dialog.


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

The issue was there we explicitly pass null as owner to ServiceDialog 
in pageDialog(attributes).

Proposed fix is to get the owner window,
if pageDialog is called before calling printDialog, the window will 
be a Frame else the owner window will be ServiceDialog

and pass this owner window to ServiceDialog instead of null.

For PrintDialog, the proposed fix is to set an attribute with 
DialogOwner so that ServiceUI dialog can parse that attribute and can 
use the owner window as parent of the dialaog,


Regards
Prasanta

[OpenJDK 2D-Dev] [9] RFR 8165146 [PIT][TEST_BUG] Doubtful usability of java/awt/print/PrinterJob/TestMediaTraySelection.java

[Prasanta Sadhukhan]

Hi All,

It seems there is a question mark on the usability of the testcase if 
the user does not have a printer that does not have multiple trays.
The testcase might be useful for dev environment so removing @test tag 
to prevent it running from jtreg harness.

Please review.

 hg diff test/java/awt/print/PrinterJob/TestMediaTraySelection.java
diff -r 145d979bb1fb 
test/java/awt/print/PrinterJob/TestMediaTraySelection.java
--- a/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Tue Aug 
30 11:07:58 2016 +0530
+++ b/test/java/awt/print/PrinterJob/TestMediaTraySelection.java Wed Aug 
31 22:25:53 2016 +0530

@@ -21,8 +21,7 @@
  * questions.
  */
 /*
- * @test
- * @bug 6357887
+ * @bug 6357887 8165146
  * @summary  Verifies if selected printertray is used

Regards
Prasanta

Re: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails

[Vadim Pakhnushev]

+1

Vadim

On 31.08.2016 16:05, Prem Balakrishnan wrote:


Hi Vadim,

Thankyou for the Review.

I have updated the patch as per review comments,

http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.03/ 



>According to the comments in the 
TranslucentWindowPainter.createInstance you will get BIWindowPainter 
even for OpenGL pipeline unless you force optimized path via 
>sun.java2d.twp.forceopt so you will need to check these paths in the 
fix for OpenGL.


 Yes, BIWindowPainter get called in OpenGl pipleline , I am working on 
OpenGL rendering issue(8164811).


Regards,

Prem

*From:*Vadim Pakhnushev
*Sent:* Wednesday, August 31, 2016 5:00 PM
*To:* Prem Balakrishnan; Sergey Bylokhov; 2d-dev@openjdk.java.net
*Subject:* Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java 
fails


Prem,

I believe it's possible to use AccelSurface.getBounds() method and 
skip casting to SurfaceData completely.

The calculations are basically the same.

According to the comments in the 
TranslucentWindowPainter.createInstance you will get BIWindowPainter 
even for OpenGL pipeline unless you force optimized path via 
sun.java2d.twp.forceopt so you will need to check these paths in the 
fix for OpenGL.


Thanks,
Vadim

On 30.08.2016 9:17, Prem Balakrishnan wrote:

Reminder

*From:*Prasanta Sadhukhan
*Sent:* Friday, August 26, 2016 12:08 PM
*To:* Prem Balakrishnan; 2d-dev@openjdk.java.net

*Subject:* Re: Review Request: JDK-8144735 [hidpi]

javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
fails

Ok. so long you are addressing the opengl issue albeit via
different bugid, it's ok with me. +1.

Regards
Prasanta

On 8/26/2016 11:56 AM, Prem Balakrishnan wrote:

Hi Prasanta,

Thankyou for the review.

The code compiles , Actual scenario is as below:

public class Temp {

AccelSurface as = new AccelSurface() {};

SurfaceData sd = (SurfaceData)as;

}

class SurfaceData {}

interface Surface {}

interface AccelSurface extends Surface{}

class D3DSurfaceData extends SurfaceData implements AccelSurface{}

class OGLSurfaceData extends SurfaceData implements AccelSurface{}

---

In suggested fix, the SurfaceData is always of type
D3DSurfaceData.

And hence getDefaultScaleX/Y holds good. OpenGL rendering is
handled in a different flow.

http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/


Suggested fix also resolves the following failures on hidpi
windows 8

javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java


javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java


javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java


javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java


javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java


javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java

--
OpenGL Rendering issue will be addressed in JDK-8164811




Regards,

Prem

*From:*Prasanta Sadhukhan
*Sent:* Monday, August 22, 2016 12:32 PM
*To:* Prem Balakrishnan; Rajeev Chamyal;
awt-...@openjdk.java.net ;
2d-dev@openjdk.java.net 
*Subject:* Re: Review Request: JDK-8144735 [hidpi]

javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
fails

I wonder how it compiles?
I tried a small program
--
public class Test {
AccelSurface b = new AccelSurface();
SurfaceData c = (SurfaceData)b;
}

class SurfaceData extends Surface {}
class Surface {}
class AccelSurface extends Surface {}
-
and it fails to compile
Test.java:3: error: incompatible types: AccelSurface cannot be
converted to SurfaceData
SurfaceData c = (SurfaceData)b;

ANyways, did you check with opengl pipeline? It seems
getDefaultScaleX/Y is not present in OGLSurfaceData which will
result in falling back to SurfaceData in which case the scale
will be 1.

Regards
Prasanta

On 8/18/2016 3:12 PM, Prem Balakrishnan wrote:

Added “2d-dev” team for review

Re: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails

[Prem Balakrishnan]

Hi Vadim,

 

Thankyou for the Review.

 

I have updated the patch as per review comments,

http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.03/ 

 

>According to the comments in the TranslucentWindowPainter.createInstance you 
>will get BIWindowPainter even for OpenGL pipeline unless you force optimized 
>path via >sun.java2d.twp.forceopt so you will need to check these paths in the 
>fix for OpenGL.

 Yes, BIWindowPainter get called in OpenGl pipleline , I am working on OpenGL 
rendering issue(8164811).

 

Regards,

Prem

 

From: Vadim Pakhnushev 
Sent: Wednesday, August 31, 2016 5:00 PM
To: Prem Balakrishnan; Sergey Bylokhov; 2d-dev@openjdk.java.net
Subject: Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
 fails

 

Prem,

I believe it's possible to use AccelSurface.getBounds() method and skip casting 
to SurfaceData completely.
The calculations are basically the same.

According to the comments in the TranslucentWindowPainter.createInstance you 
will get BIWindowPainter even for OpenGL pipeline unless you force optimized 
path via sun.java2d.twp.forceopt so you will need to check these paths in the 
fix for OpenGL.

Thanks,
Vadim

On 30.08.2016 9:17, Prem Balakrishnan wrote:

Reminder

 

From: Prasanta Sadhukhan 
Sent: Friday, August 26, 2016 12:08 PM
To: Prem Balakrishnan; HYPERLINK 
"mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
 fails

 

Ok. so long you are addressing the opengl issue albeit via different bugid, 
it's ok with me. +1.

Regards
Prasanta

On 8/26/2016 11:56 AM, Prem Balakrishnan wrote:

Hi Prasanta,

 

Thankyou for the review.

 

The code compiles , Actual scenario is as below:

public class Temp {



AccelSurface as = new AccelSurface() {};

SurfaceData sd = (SurfaceData)as;

}

class SurfaceData {}

interface Surface {}

interface AccelSurface extends Surface{}

class D3DSurfaceData extends SurfaceData implements AccelSurface{}

class OGLSurfaceData extends SurfaceData implements AccelSurface{}

---

In suggested fix, the SurfaceData is always of type D3DSurfaceData.

And hence getDefaultScaleX/Y holds good. OpenGL rendering is handled in a 
different flow.

HYPERLINK 
"http://cr.openjdk.java.net/%7Epkbalakr/8144735/webrev.02/"http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/

Suggested fix also resolves the following failures on hidpi windows 8

javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java 
javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java
 
javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java 
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java
 
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java
 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java

--
OpenGL Rendering issue will be addressed in HYPERLINK 
"https://bugs.openjdk.java.net/browse/JDK-8164811"JDK-8164811 



 

Regards,

Prem

 

From: Prasanta Sadhukhan 
Sent: Monday, August 22, 2016 12:32 PM
To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK 
"mailto:awt-...@openjdk.java.net"awt-...@openjdk.java.net; HYPERLINK 
"mailto:2d-dev@openjdk.java.net"2d-dev@openjdk.java.net
Subject: Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
 fails

 

I wonder how it compiles?
I tried a small program
--
public class Test {
AccelSurface b = new AccelSurface();
SurfaceData c = (SurfaceData)b;
}

class SurfaceData extends Surface {}
class Surface {}
class AccelSurface extends Surface {}
-
and it fails to compile 
Test.java:3: error: incompatible types: AccelSurface cannot be converted to 
SurfaceData
SurfaceData c = (SurfaceData)b;

ANyways, did you check with opengl pipeline? It seems getDefaultScaleX/Y is not 
present in OGLSurfaceData which will result in falling back to SurfaceData in 
which case the scale will be 1.

Regards
Prasanta

On 8/18/2016 3:12 PM, Prem Balakrishnan wrote:

 

Added "2d-dev" team for review

 

Regards,

Prem

 

From: Alexandr Scherbatiy 
Sent: Thursday, August 18, 2016 2:57 PM
To: Prem Balakrishnan; Rajeev Chamyal; HYPERLINK 
"mailto:awt-...@openjdk.java.net"awt-...@openjdk.java.net; Sergey Bylokhov
Subject: Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
 fails

 

Could you also send the review to the 2d-dev alias?

Thanks,
Alexandr.

On 8/18/2016 9:59 AM, Prem Balakrishnan wrote:

Hi Alexandr,

 

AccelSurface is implemented by *ONLY* D3DSurfaceData and OGLSurfaceData classes,

Both of these c

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

[Jayathirth D V]

Thanks for the review Sergey.

-Original Message-
From: Sergey Bylokhov 
Sent: Wednesday, August 31, 2016 6:08 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 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 use same reader for 
 another read() call it will be invalid unless we clear previous abort 
 request.

 In case of JPEG since we are using native IJG library we need to update 
 abortFlag present in imageioJPEG.c before every call as we are doing for 
 other readers using clearAbortRequest().

 Since this has native and make changes I have verified changes 
 through JPRT also which is successfully building on all platforms 
 (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.
 client_commit//JobStatus.txt )

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

 I noticed that in case on WBMP I was not getting ImageReader object to 
 call setInput() in test case to verify the behavior of reader.abort(). So 
 I have created separate bug for the same 
 (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP 
 we already have clearAbortRequest() call and also we are returning from 
 IIOReadProgressListener callbacks properly, only thing here is we are not 
 returning right after callbacks as we have updated other plugins.

 I want to verify writer plugins in separate bug as we already have lot of 
 changes in this bug. So I have created 
 https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on 
 this bug.

 Thanks,
 Jay

 

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

[Sergey Bylokhov]

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 use same reader for 
another read() call it will be invalid unless we clear previous abort request.

In case of JPEG since we are using native IJG library we need to update 
abortFlag present in imageioJPEG.c before every call as we are doing for other 
readers using clearAbortRequest().

Since this has native and make changes I have verified changes
through JPRT also which is successfully building on all platforms
(http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.
client_commit//JobStatus.txt )

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

I noticed that in case on WBMP I was not getting ImageReader object to call 
setInput() in test case to verify the behavior of reader.abort(). So I have 
created separate bug for the same 
(https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we 
already have clearAbortRequest() call and also we are returning from 
IIOReadProgressListener callbacks properly, only thing here is we are not 
returning right after callbacks as we have updated other plugins.

I want to verify writer plugins in separate bug as we already have lot of 
changes in this bug. So I have created 
https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this 
bug.

Thanks,
Jay

-Original Message-
From: Phil Race
Sent: Thursday, August 18, 2016 1:42 AM
To: Sergey Bylokhov
Cc: Jayathirth D V; 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

I think we can
- get all plugins,and for each
- write a file in that format
- read it back and apply the test

It is also worth verifying that the writer abort checks are in sync with the 
reader aborts, ie happen at such equivalent points as might exist.

-phil.

On 08/15/2016 11:30 AM, Sergey Bylokhov wrote:

Is it possible to unify the test for all our plugins? I assume they
should work in the same way. I am not sure bu

Re: [OpenJDK 2D-Dev] Review Request: JDK-8144735 [hidpi] javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java fails

[Vadim Pakhnushev]

Prem,

I believe it's possible to use AccelSurface.getBounds() method and skip 
casting to SurfaceData completely.

The calculations are basically the same.

According to the comments in the TranslucentWindowPainter.createInstance 
you will get BIWindowPainter even for OpenGL pipeline unless you force 
optimized path via sun.java2d.twp.forceopt so you will need to check 
these paths in the fix for OpenGL.


Thanks,
Vadim

On 30.08.2016 9:17, Prem Balakrishnan wrote:


Reminder

*From:*Prasanta Sadhukhan
*Sent:* Friday, August 26, 2016 12:08 PM
*To:* Prem Balakrishnan; 2d-dev@openjdk.java.net
*Subject:* Re: Review Request: JDK-8144735 [hidpi] 
javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java 
fails


Ok. so long you are addressing the opengl issue albeit via different 
bugid, it's ok with me. +1.


Regards
Prasanta

On 8/26/2016 11:56 AM, Prem Balakrishnan wrote:

Hi Prasanta,

Thankyou for the review.

The code compiles , Actual scenario is as below:

public class Temp {

AccelSurface as = new AccelSurface() {};

SurfaceData sd = (SurfaceData)as;

}

class SurfaceData {}

interface Surface {}

interface AccelSurface extends Surface{}

class D3DSurfaceData extends SurfaceData implements AccelSurface{}

class OGLSurfaceData extends SurfaceData implements AccelSurface{}

---

In suggested fix, the SurfaceData is always of type D3DSurfaceData.

And hence getDefaultScaleX/Y holds good. OpenGL rendering is
handled in a different flow.

http://cr.openjdk.java.net/~pkbalakr/8144735/webrev.02/


Suggested fix also resolves the following failures on hidpi windows 8

javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucent.java


javax/swing/JWindow/ShapedAndTranslucentWindows/PerPixelTranslucentGradient.java

javax/swing/JWindow/ShapedAndTranslucentWindows/SetShapeAndClickSwing.java


javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java


javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedTranslucentPerPixelTranslucentGradient.java


javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java

--
OpenGL Rendering issue will be addressed in JDK-8164811




Regards,

Prem

*From:*Prasanta Sadhukhan
*Sent:* Monday, August 22, 2016 12:32 PM
*To:* Prem Balakrishnan; Rajeev Chamyal; awt-...@openjdk.java.net
; 2d-dev@openjdk.java.net

*Subject:* Re: Review Request: JDK-8144735 [hidpi]

javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
fails

I wonder how it compiles?
I tried a small program
--
public class Test {
AccelSurface b = new AccelSurface();
SurfaceData c = (SurfaceData)b;
}

class SurfaceData extends Surface {}
class Surface {}
class AccelSurface extends Surface {}
-
and it fails to compile
Test.java:3: error: incompatible types: AccelSurface cannot be
converted to SurfaceData
SurfaceData c = (SurfaceData)b;

ANyways, did you check with opengl pipeline? It seems
getDefaultScaleX/Y is not present in OGLSurfaceData which will
result in falling back to SurfaceData in which case the scale will
be 1.

Regards
Prasanta

On 8/18/2016 3:12 PM, Prem Balakrishnan wrote:

Added “2d-dev” team for review

Regards,

Prem

*From:*Alexandr Scherbatiy
*Sent:* Thursday, August 18, 2016 2:57 PM
*To:* Prem Balakrishnan; Rajeev Chamyal;
awt-...@openjdk.java.net ;
Sergey Bylokhov
*Subject:* Re: Review Request: JDK-8144735 [hidpi]

javax/swing/JWindow/ShapedAndTranslucentWindows/TranslucentPerPixelTranslucentGradient.java
fails

Could you also send the review to the 2d-dev alias?

Thanks,
Alexandr.

On 8/18/2016 9:59 AM, Prem Balakrishnan wrote:

Hi Alexandr,

AccelSurface is implemented by *ONLY* D3DSurfaceData and
OGLSurfaceData classes,

Both of these classes extend SurfaceData as well.

Hence, casting of 'as' variable which is of type
AccelSurface object to SurfaceData is always VALID.

Regards,
Prem

*From:*Alexandr Scherbatiy
*Sent:* Wednesday, August 17, 2016 4:42 PM
*To:* Prem Balakrishnan; Rajeev Chamyal;
awt-...@openjdk.java.net
; Sergey Bylokhov
*Subject:* Re: Review Request: JDK-8144735 [hidpi]

javax/swing

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

[Jayathirth D V]

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);

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

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 use same reader for 
>>> another read() call it will be invalid unless we clear previous abort 
>>> request.
>>>
>>> In case of JPEG since we are using native IJG library we need to update 
>>> abortFlag present in imageioJPEG.c before every call as we are doing for 
>>> other readers using clearAbortRequest().
>>>
>>> Since this has native and make changes I have verified changes 
>>> through JPRT also which is successfully building on all platforms 
>>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.
>>> client_commit//JobStatus.txt )
>>>
>>> Please find updated webrev for review:
>>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/
>>>
>>> I noticed that in case on WBMP I was not getting ImageReader object to call 
>>> setInput() in test case to verify the behavior of reader.abort(). So I have 
>>> created separate bug for the same 
>>> (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we 
>>> already have clearAbortRequest() call and also we are returning from 
>>> IIOReadProgressListener callbacks properly, only thing here is we are not 
>>> returning right after callbacks as we have updated other plugins.
>>>
>>> I want to verify writer plugins in separate bug as we already have lot of 
>>> changes in this bug. So I have created 
>>> https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on 
>>> this bug.
>>>
>>> Thanks,
>>> Jay
>>>
>>> -Original Message-
>>> From: Phil Race
>>> Sent: Thursday, August 18, 2016 1:42 AM
>>> To: Sergey Bylokhov
>>> Cc: Jayathirth D V; 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
>>>
>>> I think we can
>>> - get all plugins,and for each
>>> - write a file in that format
>>> - read it back and apply the test
>>>
>>> It is also worth verifying that the writer abort checks are in sync with 
>>> the reader aborts, ie h

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

[Sergey Bylokhov]

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 use same reader for 
another read() call it will be invalid unless we clear previous abort request.

In case of JPEG since we are using native IJG library we need to update 
abortFlag present in imageioJPEG.c before every call as we are doing for other 
readers using clearAbortRequest().

Since this has native and make changes I have verified changes through
JPRT also which is successfully building on all platforms
(http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.
client_commit//JobStatus.txt )

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

I noticed that in case on WBMP I was not getting ImageReader object to call 
setInput() in test case to verify the behavior of reader.abort(). So I have 
created separate bug for the same 
(https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we 
already have clearAbortRequest() call and also we are returning from 
IIOReadProgressListener callbacks properly, only thing here is we are not 
returning right after callbacks as we have updated other plugins.

I want to verify writer plugins in separate bug as we already have lot of 
changes in this bug. So I have created 
https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this 
bug.

Thanks,
Jay

-Original Message-
From: Phil Race
Sent: Thursday, August 18, 2016 1:42 AM
To: Sergey Bylokhov
Cc: Jayathirth D V; 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

I think we can
- get all plugins,and for each
- write a file in that format
- read it back and apply the test

It is also worth verifying that the writer abort checks are in sync with the 
reader aborts, ie happen at such equivalent points as might exist.

-phil.

On 08/15/2016 11:30 AM, Sergey Bylokhov wrote:

Is it possible to unify the test for all our plugins? I assume they
should work in the same way. I am not sure but probably the image can
be generated at runtime?

On 11.08.16 21:59, Jayathirth D V wrote:

Hi,



Please review the following fix in JDK9 at your convenience:



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



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



Issue : When we issue ImageReader.abort() in
IIOReadProgressListener.imageStarted(), reading is not aborted and
it is continued.



Root cause : After IIOReadProgressListener.imageStarted() call in
PNGImageReader.java when we enter decodeImage() we call
clearAbortRequest() which will clear the abort request from
IIOReadProgressListener.imageStarted().



Solution : clearAbortRequest() documentation mentions that it should
be called before reading of image starts, so it should be called
before IIOReadProgressListener.image

Re: [OpenJDK 2D-Dev] RFR: 8144015: [PIT] failures of text layout font tests

[Prasanta Sadhukhan]

Looks ok to me.

Regards
Prasanta
On 8/26/2016 2:40 AM, Phil Race wrote:


Webrev: http://cr.openjdk.java.net/~prr/8144015/

This RFR encompasses changes that are sufficiently related
to keep them all together and they deserve testing as a whole.
Multiple test failures are resolved. A list is below.

Notable highlights
ExtendedTextSourceLabel.createCharinfo() can now handle
cases where the glyph count is less than the char count.
This was not just a problem in 9 (harfbuzz) but has been
observed on 8 too (8041480 in the list below).
The fundamental change is to abandon the idea of
updating in place which added complexity and was
never going to work if you had too few glyphs ..

HBShaper.c
- Fixed that kerning was always enabled
- Simplified - and corrected - the code that stored the resulting data
- Stopped using throwing an exception as a way to expand storage
- Cleaned up JNI usage

Tests have been added/updated/open sourced as necessary.

JPRT passed these changes.


Bugs fixed by this change :
https://bugs.openjdk.java.net/browse/JDK-8144015
8144015: [PIT] failures of text layout font tests

** https://bugs.openjdk.java.net/browse/JDK-8144023
8144023: [PIT] failure of text measurements in 
javax/swing/text/html/parser/Parser/6836089/bug6836089.java


** https://bugs.openjdk.java.net/browse/JDK-8145542
8145542: The case failed automatically and thrown 
java.lang.ArrayIndexOutOfBoundsException exception


** https://bugs.openjdk.java.net/browse/JDK-8151725
8151725: [macosx] ArrayIndexOOB exception when displaying Devanagari 
text in JEditorPane


** https://bugs.openjdk.java.net/browse/JDK-8144240
8144240: [macosx][PIT] AIOOB in 
closed/javax/swing/text/GlyphPainter2/6427244/bug6427244.java


https://bugs.openjdk.java.net/browse/JDK-8152680
8152680: Regression in GlyphVector.getGlyphCharIndex behaviour

** https://bugs.openjdk.java.net/browse/JDK-8158924
8158924: Incorrect i18n text document layout

** https://bugs.openjdk.java.net/browse/JDK-8041480
8041480: ArrayIndexOutOfBoundsException when JTable contains certain 
string


-phil.

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

[Jayathirth D V]

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 use same reader for 
>> another read() call it will be invalid unless we clear previous abort 
>> request.
>>
>> In case of JPEG since we are using native IJG library we need to update 
>> abortFlag present in imageioJPEG.c before every call as we are doing for 
>> other readers using clearAbortRequest().
>>
>> Since this has native and make changes I have verified changes through
>> JPRT also which is successfully building on all platforms
>> (http://scaaa637.us.oracle.com//archive/2016/08/2016-08-29-065104.jay.
>> client_commit//JobStatus.txt )
>>
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/4924727/webrev.01/
>>
>> I noticed that in case on WBMP I was not getting ImageReader object to call 
>> setInput() in test case to verify the behavior of reader.abort(). So I have 
>> created separate bug for the same 
>> (https://bugs.openjdk.java.net/browse/JDK-8164930 ). And in case of WBMP we 
>> already have clearAbortRequest() call and also we are returning from 
>> IIOReadProgressListener callbacks properly, only thing here is we are not 
>> returning right after callbacks as we have updated other plugins.
>>
>> I want to verify writer plugins in separate bug as we already have lot of 
>> changes in this bug. So I have created 
>> https://bugs.openjdk.java.net/browse/JDK-8164931 and will be working on this 
>> bug.
>>
>> Thanks,
>> Jay
>>
>> -Original Message-
>> From: Phil Race
>> Sent: Thursday, August 18, 2016 1:42 AM
>> To: Sergey Bylokhov
>> Cc: Jayathirth D V; 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
>>
>> I think we can
>> - get all plugins,and for each
>> - write a file in that format
>> - read it back and apply the test
>>
>> It is also worth verifying that the writer abort checks are in sync with the 
>> reader aborts, ie happen at such equivalent points as might exist.
>>
>> -phil.
>>
>> On 08/15/2016 11:30 AM, Sergey Bylokhov wrote:
>>> Is it possible to unify the test for all our plugins? I assume they
>>> should work in the same way. I am not sure but probably the image can
>>> be generated at runtime?
>>>
>>> On 11.08.16 21:59, Jayathirth D V wrote:
 Hi,



 Please review the following fix in JDK9 at your convenience:



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



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



 Issue : When we issue ImageReader.abort() in
 IIOReadProgressListener.imageStarted(), reading is not aborted and
 it is continued.



 Root cause : After IIOReadProgressListener.imageStarted() call in
 PNGImageReader.java when we enter decodeImage() we call
 clearAbortRequest() which will clear the abort request from
 IIOReadProgressListener.imageStarted().


>>