Hi Cameron,
Cameron McCormack <cam@xxxxxxxxx> wrote on 02/09/2007 08:40:35 AM:
> Cameron McCormack:
> > > ? flowBidi, which generates a StackOverflowException in some
> > > java.awt.font and sun.font methods
>
> Thomas DeWeese:
> > Since the other flow tests work, can you sort out what
> > method is causing the problem?
>
> It looks to be a bug in the 1.6 beta JRE. The call from Batik?s code
> is BidiAttributedCharacterIterator:121, where it creates a
> java.awt.font.TextLayout object. The AttributedString that?s passed to
> it is "Some (embedded bidi) of text.", where the text run in the
> parentheses has a BIDI_EMBEDDING attributed on it. I?ve filed a bug on
> Apple?s JRE.
Ok, sounds like it isn't a common enough case to warrant
too much digging around for a workaround (especially since it
may be fixed by the time it is released).
> > > ? batik70 (sample problem)
> > Second remove the use of the pattern and try
> > putting a few copies of the pattern directly
> > over the circles (to avoid rendering to a pattern
> > buffer that is then composited).
>
> Ok so it seems to be something to do with the going to a buffer for the
> pattern. Here?s a reduced test case:
>
> I tried to trace through the code to determine what
> ColorModel/WritableRaster/SampleModel are used so I could reproduce the
> rendering in a small test case. In the end I couldn?t, though. Do you
> have a Mac to test with?
I have a Mac but not Mac OS 10.4.
> > > ? masking-mask-BE-0[56] (same problem)
> > > ? histogramNormalization (same problem)
> > > ? feConvolveMatrix (same problem)
> >
> > So there is something funny going on with
> > alpha handling.
>
> I found the main BufferedImage that the whole document is rendered to is
> TYPE_INT_ARGB_PRE, and the pattern BufferedImage is TYPE_INT_ARGB. In
> my standalone test I tried painting a semi-opaque TYPE_INT_ARGB
> BufferedImage to a TYPE_INT_ARGB_PRE one, but it worked properly.
I would guess that this is related. IIRC we switched to ARGB_PRE
on Mac since it was much faster. I may try and see if ARGB_PRE on
Windows has the same issues.
> > > The text ones all give correct rendering with a small rotation.
> >
> > I suppose it would be an option to add a small rotation to
> > 'complex' texts (anything that adjusts individual glyph positions),
> > on Mac OS X. However since this is fixed in Java 6 I'd rather just
> > recommend people upgrade the JVM...
>
> Maybe we could set the rendering hint that corresponds to
> text-rendering="geometricPrecision" when rendering certain (or all)
> text.
This fixes it? It would be a simpler fix, but I'm not sure how
it would impact general performance.
> The 1.6 JRE isn?t released yet for OS X though, it?s just a beta (which
> can only be downloaded by signing up for Apple?s Developer Centre
> thingo).
Ok, still it shouldn't be that long before it get's rolled out
I would guess.
>
> > > > > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat
> > > >
> > > > This looks to me like it's rendering the gradient at
> > > > lower resolution than the reference.
> > > >
> > > > > http://mcc.id.au/temp/t/show?mac,gradientLimit
> > > > > Top right gradient wrong.
> > > >
> > > > Once again I wonder if it's rendering at lower resolution...
> > >
> > > Anything that could be done about these?
> >
> > I don't know, someone must be scaling the buffer we give
> > them for display. I don't know where that would be happening.
>
> Is it enough of a corner case to ignore?
I think so.
> > > > Hmm, looks like the gradient opacity is being interpreted
> > > > 'backwards'.
> > >
> > > Strange that it?s got opacity 1 on the top scan line.
> >
> > Well it's not uncommon to have a special case for opacity==1
> > since you don't need to do compositing just copy. But that
> > would indicate that there was something a little wonky inside
> > their own code.
>
> Could be part of the same compositing problem I guess.
I would guess so.
> I?m not really sure where to look though for this and the other
> alpha related problems.
Neither am I really. This code is fairly complex as it tries
to avoid Legacy problems and maintain good performance.
I'll try and reproduce it on Windows by making the destination
ARGB_PRE. If that causes the same problem then it's probably in
our code and it will give me a better idea where to look.
|
