Hi Jim,
Thanks for taking the time to review this in-depth.
I guess that also explains why the source coordinates were multiplied by the
scale, though that seems a rather odd way to handle these issues.
Indeed, the offsets could be also stored as part of the transformation
(as it is done for
Hi Clemens,
On 11/6/13 9:38 AM, Clemens Eisserer wrote:
A new question/issue - on line 314, what happens if the case is both
quadrant rotated and extra-alpha'd? Either of those will get us into that
code block, but also both of them could be true at the same time in which
case it looks like
Hi Clemens,
I sincerely apologize for not seeing this sooner, my email sorting is a
little primitive, but I should check these alternate folders more often.
The one thing I am concerned about here is the rounding that is going on
for scaled images. You removed a comment about non-integer
Ah, I see. And, I was about to rant about MT issues, but I see now that
this is all inside an AWTLock.
I guess that also explains why the source coordinates were multiplied by
the scale, though that seems a rather odd way to handle these issues.
A new question/issue - on line 314, what
Hello Clemens,
the change in XRPMBlitLoops.java looks good to me.
The part of the fix in XRUtils.java should probably be
ignored now.
Thanks,
Andrew
On 10/18/2013 3:45 PM, Clemens Eisserer wrote:
Another revision was required, available at:
Another revision was required, available at:
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.04/
When the destination-area is quadratic, no geometry is stored inside
the mask and therefore the composition-window is used for clipping and
it's size has to be rounded properly.
In cases where it
Clemens,
This looks good to me. I used the Java 2D demo to test it.
What were you using as a test ?
I'll need to file a new bug to commit this additional fix.
I'll push once Jim has OK'd this too.
-phil.
On 10/18/2013 4:45 AM, Clemens Eisserer wrote:
Another revision was required,
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
As usual, seconds after sending a review request I somewhere find
another issue - sorry.
Please instead of webrev.01, review
http://cr.openjdk.java.net/~ceisserer/fix12/webrev.02/
In the previous version, I assumed not using a mask means a
quadrant-rotated transform, which is not correct as the
Hi,
As Jim pointed out, my earlier fix for bug JDK-7159455 wasn't entirely
correct as it allowed some shear-transformations to pass a check for a
fast-path although they should have been rejected. He proposed a way
of using the capabilities already provided by AffineTransform, which
is correct,
Hi Clemens,
Now that we've narrowed it down to a quadrant rotation at best, can't we
get by with only transforming x,y and x+w,y+h? Or is the adjust method
used from other locations that might have a non-quadrant transform? (Or
do any callers depend on srcCoords and dstCoords being fully
11 matches
Mail list logo
