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
