Hello Clemens, I have played with the tests, and Java2D demo, and the fix looks fine to me.
Thanks, Andrew On 10/20/2013 9:55 PM, Clemens Eisserer wrote:
Hi, Ok, this starts to become embarrassing ... sorry for the review request spam recently. I was stressed that my changes would be submitted too late, so I submitted as soon as I had a fix for an isolated issue. During extensive testing I've found a few other issues within the xrender pipeline paint support. Please review the latest (and from my side last) revision of the patch: http://cr.openjdk.java.net/~ceisserer/fix13/webrev.03/ Additional changes/fixes compared to webrev.02 are: 1. The xrender pipeline "accelerated" LinearRGB color model gradients, although xrender (from what I found out) only supports sRGB. The pipeline now falls back to software loops when a LinearRGB gradient is requested. (Test: http://cr.openjdk.java.net/~ceisserer/fix13/LinearColorSpaceGradientTest.java ) 2. An AffineTransform can be specified when creating a linear or radial gradient paint. This transform was not applied correctly. The fix makes use of the same mechanisms introduced for TexturePaint's transform support introduced in webrev.02 and does away with special transform handling previously performed at gradient construction time. (Test: http://cr.openjdk.java.net/~ceisserer/fix13/GradientTransformTest.java ) 3. The interpolation value set for a TexturePaint at creation time was never changed. Therefore, switching to bilinear interpolation is ignored in case the TexturePaint was created with the rendering hint set to nearest neighbour. There is already is a mechanism for re-validating source-surface properties, so this has been extended to revalidate the interpolation setting too. This issue is also present in the OpenGL pipeline (didn't test d3d). (Test: http://cr.openjdk.java.net/~ceisserer/fix13/TexturePaintInterpolationTest.java ) Thanks, Clemens