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
