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
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
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 ..
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
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
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
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,
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
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
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 :
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
11 matches
Mail list logo