Pushed ..
-phil.
On 09/28/2016 12:41 PM, Sergey Bylokhov wrote:
Thanks.
On 28.09.16 8:45, Clemens Eisserer wrote:
HI Jim,
All of those conditions are optimized equivalents to getting the
determinant.
invert() is a destructive call, but since getTransform is documented to
return a copy,
Thanks.
On 28.09.16 8:45, Clemens Eisserer wrote:
HI Jim,
All of those conditions are optimized equivalents to getting the
determinant.
invert() is a destructive call, but since getTransform is documented to
return a copy, that is fine - but getDeterminant() will involve less math to
check
HI Jim,
> All of those conditions are optimized equivalents to getting the
> determinant.
>
> invert() is a destructive call, but since getTransform is documented to
> return a copy, that is fine - but getDeterminant() will involve less math to
> check the condition...
Thanks for the
All of those conditions are optimized equivalents to getting the determinant.
invert() is a destructive call, but since getTransform is documented to return a copy, that is fine - but
getDeterminant() will involve less math to check the condition...
...jim
On 9/27/16
+1
-phil.
On 9/27/2016 2:17 AM, Clemens Eisserer wrote:
Hello again,
OK .. should be part of the patch tho'
Just noticed the reg tests are also open-source, until now I thought
they are integrated into some Oracle-only internal test collection.
Cool!
Please find the current version of the
Hi Sergey
> I guess you can use "getDeterminant()==0" to determine if this transform has
> no inverse?
Initially I had the same idea, but looking at the implementation of
invert(), I found several different conditions leading to an
NoninvertibleTransformException. So I decided to keep the call
Hi,
On 26.09.16 22:50, Clemens Eisserer wrote:
I was not 100% sure myself. As the Paint classes are stateless, there
is some overhead involved in checking the transformation in
isPaintValid (allocation of an additional AffineTransformation by
calling MultipleGradientPaint.getTransform() +
Hello again,
> OK .. should be part of the patch tho'
Just noticed the reg tests are also open-source, until now I thought
they are integrated into some Oracle-only internal test collection.
Cool!
Please find the current version of the patch at:
http://93.83.133.214/8162591/webrev.03/
It
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
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
13 matches
Mail list logo
