[OpenJDK 2D-Dev] Request for review: Additional fix for JDK-7159455

[Clemens Eisserer]

Hi,

Please find an updated webrev with your suggestions at:
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.01/

> Am I reading this right.  You are saying that it is used in a mixture of
> cases and some of those will support full transforms?
Exactly.

> What I was suggesting is that the adjust method can do more optimal work if
> the transform is quadrant-rotated and so it needs to know that information
> as well.  I'm not suggesting changing the technique for determining the type
> of rotation,
Done.
If you prefer I could also write a single-if version,
which would be more pretty but also contain some duplicate code.

> This would depend on the semantics of the draw operation.  I believe that
> other places in our other pipelines are consistent with "round-down"
> semantics and so this pipeline should be consistent.  This may be worth
> writing a test that slowly translates an image to see when it jumps pixels,
> especially if it can be automated, so that we can keep all of the pipelines
> in synch.
I can confirm the round-down bahaviour at least for the software-loops.
Once I did a test slowly scaling an image, but jump-points were
different between the ogl/d3d, xrender and software pipelines.

> I agree that floor/ceil sounds more correct for this case.
>
> Perhaps we need a boolean for the adjust method?  Or is there a case where
> the caller may use it in different ways and doesn't know which way is
> appropriate before it calls the method?
No there isn't, so I implemented it this way ;)

Thanks, Clemens