Re: [OpenJDK 2D-Dev] [9] RFR JDK-8164931 : Verify if writer.abort() works properly for all writers in IIOWriteProgressListener.

2016-09-26 Thread Brian Burkhalter
My off-list question was this: > I am probably missing something, but with respect to the TIFF writer, why is > it necessary to move old lines 2607-2610 to new lines 2596-2599? In the old > version, for whatever it’s worth, the tile offset and byte count are written > before the abort, so if

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8164931 : Verify if writer.abort() works properly for all writers in IIOWriteProgressListener.

2016-09-26 Thread Philip Race
Seems OK .. modulo Brian's off-list question about TIFF -phil. On 9/20/16, 10:57 PM, Jayathirth D V wrote: Hi Prasanta, Thanks for your review. When we are writing embedded image we have internal WriteProgressAdapter in which we have dummy listener functions which are doing nothing. So there

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-26 Thread Philip Race
On 9/26/16, 12:50 PM, Clemens Eisserer wrote: Thanks a lot for the feedback. The fix seems fine .. is there a possibility to have a regression test? Perhaps based on the code in the bug ? Please find an automated regression test at: http://93.83.133.214/8162591/HugeGradientTest.java OK ..

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-26 Thread Clemens Eisserer
Thanks a lot for the feedback. > The fix seems fine .. is there a possibility to have a regression test? > Perhaps based on the code in the bug ? Please find an automated regression test at: http://93.83.133.214/8162591/HugeGradientTest.java > Should we also check the transform? > I guess we

Re: [OpenJDK 2D-Dev] Different rounding applied by ProcessPath and ShapeSpanIterator

2016-09-26 Thread Jim Graham
Trying to remember some ancient reasoning (and probably failing at the memory thing), I think the original issue was that the existing non-AA rasterizer could only output spans, so rendering a tall line (one with a wide Y range) would result in a lot of rendering operations being sent to a hw

Re: [OpenJDK 2D-Dev] Different rounding applied by ProcessPath and ShapeSpanIterator

2016-09-26 Thread Jim Graham
They do operate differently. They aren't meant to be mixed and matched. One thing that may shed some light is the STROKE_CONTROL hint. If it is sent to Pure then there is no heuristic for how to rasterize and all rasterizers should agree on how to scan convert shapes. But, if it is set to

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-26 Thread Sergey Bylokhov
Hi, Clemens. Should we also check the transform? I guess we already do this in some way, but is it enough? try { at.invert(); } catch (NoninvertibleTransformException ex) { ex.printStackTrace(); } On 26.09.16 18:48, Clemens Eisserer wrote: Hello,

Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-26 Thread Philip Race
Clemens, The fix seems fine .. is there a possibility to have a regression test? Perhaps based on the code in the bug ? -phil. On 9/26/16, 8:48 AM, Clemens Eisserer wrote: Hello, The cause of JDK-8162591 is Java2D's gradient implementation allowing for coordinates to be specified using

[OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-26 Thread Clemens Eisserer
Hello, The cause of JDK-8162591 is Java2D's gradient implementation allowing for coordinates to be specified using floating point values, whereas XRender is limited to a 16.16 fixed point format - which can therefor easily overflow. This patch checks whether the supplied coordinates can be

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8166685: We should unpin stream and pixel buffer in case of setjmp during writeImage in JPEG.

2016-09-26 Thread Prasanta Sadhukhan
looks ok. Additionally, Shouldn't we call RELEASE_ARRAYS before 2934 return data->abortFlag; Regards Prasanta On 9/26/2016 1:05 PM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8166685 Webrev :

Re: [OpenJDK 2D-Dev] [9] RFR JDK-8165947: One more page printed before the test page with OpenJDK.

2016-09-26 Thread Jayathirth D V
Hi Prasanta,   Changes are working fine.   Thanks, Jay   From: Prasanta Sadhukhan Sent: Friday, September 23, 2016 10:54 PM To: Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8165947: One more page printed before the test page with OpenJDK.   Yes, sorry. Done