Hi Stephen,
Stephen Drake <[EMAIL PROTECTED]> wrote on 11/09/2006 02:03:12 AM:
> Thanks for your help - I have had some success now in displaying
> smooth-edged, rotated images with several of the methods described.
Glad to help (if I did ;).
> thomas.deweese wrote:
> >
> > So the image is broken into tiles, but they are aligned properly. I
> > suspect that the anti-aliasing you see on Mac OS X is causing the
> > tile edges to be visible even when they shouldn't be.
> >
> Indeed - I displayed each tile scaled up in a separate window, and it
was
> clear that they were anti-aliased along the top and left edges. I think
> I've seen this behaviour on the Mac before. One way around it is to
extend
> the clip area as in the patch below:
Hmm, I wonder if we can eliminate the clip completely. It's
introduced in the 'GraphicsUtil.createGraphics' We used to use
this so we could calculate the size of the output rendering buffer.
I think most of that has moved to using 'getDestination'/
'getDestinationBounds'.
> This stops the tile edges from showing in clip and mask operations.
Thanks for tracking this down, I'll try at least outsetting
the clip for Mac.
> I guess this kind of thing is also what causes lines to appear
> sometimes when a dynamic document is updated on the Mac.
Possible.
> thomas.deweese wrote:
> >
> > Another method to try would be to put the image with the mask in
> > a pattern and fill a rotated rect with that. You might not even need
> > to mask the image in this case.
> >
> This works perfectly wrt shape rendering (no mask required), but on the
Mac
> the image is blocky - it looks like it is rendered at the size of the
> pattern and then scaled up.
Hmm, this would be very odd. I have a hard time imagining what
would cause that.
> I wrote in my original post:
> > ii) Apply a mask to the image. This looks great on Windows and
Linux,
> > but on OS X ... it looks like gradients that would smooth the edge out
have
> > been applied the wrong way around, mirrored.
> This problem appears to arise when the mask is converted to a luminance
> colorspace using Any2LumRed. I have attached a patch below which works
for
> me on Mac, Windows and Linux, all with various revisions of Java 1.5.
The
> source code mentions a bug in ColorConvertOp, and my patch attempts to
> remove the workaround for that bug.
You go a little bit too far though. The divide out of alpha is
important, It's the middle part of your patch (the construction of
destBI) that can safely be skipped (as well as the copyBand at the
end), the coerceData calls are still needed I think.
> I don't know the history though, so I can't tell if the bug has
> been fixed in a subsequent Java release or if it applies to a
> situation other than what I am testing.
Once again thanks for the time to track this stuff down!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
