Hi Cameron, Cameron McCormack <[EMAIL PROTECTED]> 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
