[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] request for review: xrender pipeline ignores center-coordinates of RadialGradie
From:       Phil Race <philip.race () oracle ! com>
Date:       2013-10-22 20:55:37
Message-ID: 5266E649.8000906 () oracle ! com
[Download RAW message or body]

This looks good. I am committing it and 2 of the new tests.

http://cr.openjdk.java.net/~ceisserer/fix13/TexturePaintInterpolationTest.java

will indeed fail on D3D & OpenGL. I'll file a bug on that, so I won't 
commit the test,
just put it in the bug report.

It passes on X11, GDI,

The other 2 tests pass on X11, XRender, D3D, GDI and OpenGL (inc. on OS X)

-phil.

On 10/20/2013 10:55 AM, 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

[prev in list] [next in list] [prev in thread] [next in thread]