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

[Jim Graham]

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 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 you forego the retreival of the EA mask...?

			...jim

On 11/5/13 1:24 PM, Clemens Eisserer wrote:
> Hi Jim,
>
>> I sincerely apologize for not seeing this sooner, my email sorting is a little primitive,
>> but I should check these alternate folders more often.
> Never mind :)
>
>> 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 coordinates that I
>> think is germane.  In particular, if a scale is animating and an image is
>> rendered to 0,0=>10,10 and then 0,0=>10.25,10.25 then the pixels chosen will
>> subtly change, but the code there rounds the coordinates to integers so you
>> would see no change.  While the bounds of the result would be correct, the
>> exact pixels chosen from the source image for each pixel in the destination
>> would not be quite right.  Where can you communicate to the
>> maskBuffer.compositeBlit() method that, while the coordinates given
>> represent the bounds of interest, they aren't the exact definition of the
>> precise scaling parameters in play?
>
> The scaling parameters are stored as properties of the xrender source
> surface and are set within the validateAsSource() method, while the
> parameters passed to the compositeBlit()-function only specify the
> size of the composition window.
>
> Regards, Clemens
>