Hi Cameron, Cameron McCormack <[EMAIL PROTECTED]> wrote on 02/06/2007 08:39:39 PM:
> Thomas DeWeese: > > With the possible exception of italic text it looks to me > > like these are all just cases of the Mac OS X glyph vector > > class being hopelessly broken. Can you try adding a small > > amount of rotation and seeing if that fixes most of these, > > like it does for the 'flow text' stuff? > > > > Also are all these still broken in Java 6? > > I tried these all again on the 1.6 beta JRE on OS X. Everything now > renders properly except: Ok, this is very good news. > ? flowBidi, which generates a StackOverflowException in some > java.awt.font and sun.font methods Since the other flow tests work, can you sort out what method is causing the problem? > ? batik70 (sample problem) I think the stroking problem on the 'i' is just a flaw in the Mac OS X stroker. I can't think of anything we can do. I checked to make sure that we add a 'close_path' in this case. For the background pattern I would try two things to try and sort things out. First remove the innerShadow filter on the ellipses. See if the color of the pattern goes back to normal. 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). > ? masking-mask-BE-0[56] (same problem) > ? histogramNormalization (same problem) > ? feConvolveMatrix (same problem) So there is something funny going on with alpha handling. I wonder if we aren't falling into our optimized code for MultiplyAlphaRed. The other possibility is that we might be getting the alpha pre-multipled state wrong (or the mac jvm doesn't handle one of the pre-multiplied states correctly). > 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... > > > 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. > > > http://mcc.id.au/temp/t/show?mac,gradientPoint > > > Gradients wrong. Got this ouptut on the console, so it may be a VM > > > bug: > > > > It looks that way, perhaps it's requesting a _huge_ gradient > > bitmap (I noticed Mac OS X requests the entire gradient block at > > once instead of in small tiles). > > > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05 > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06 > > > Mask gradient wrong. > > > > 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. But I'm actually leaning towards the problem being when the alpha is or isn't premultiplied (although I must admit that I'm having a hard time understanding how you get the result we see from that). > > > ? Non pixel aligning > > > > I don't know is this really important? I suspect > > that it might be related to the fact that the Sun JVM > > likes to snap end points to pixels, so it's possible > > that the Mac OS rendering is the more 'correct' one. > > We turn off the pixel snap when you set shape-rendering > > to "geometricPrecision". You might see if they > > render the same under that setting if so I would > > write this off as unimportant (it can be controlled > > through content). > > Yeah, adding shape-rendering="crispEdges" draws the lines > exactly on the pixels. > > > > ? Opacity > > > > For the most part these are subtle. The 'paintOpacity' > > test starts to get bad. I wonder if they aren't > > just compositing in a different color space (linear for > > example). > > Possibly. How can the colour space for compositing be controlled on the > Graphics2D? I think it should always use the destinations color space. I wonder if they aren't moving bitmaps over to the graphics card to do the compositing in HW? Still don't have any idea how we might work around that though... > > > ? Miscellaneous > > Well, we do the masking implementation so I'm not sure how they > > could make it aliased. Perhaps when we draw into the mask buffer > > we don't turn on anti-aliasing. > > Hmm, that?s done in gvt.filter.MaskRable8Bit.createRendering yes? It > looks to use the same method of painting to a buffer that other things > use (getGraphicsNodeRable) so I dunno why it would not anti-alias. Once again I'm willing to blame a fundamental problem in the handling of transparent regions, with special case handling for fully opaque (so just like mask-BE-05 once the alpha is slightly less than 1 it goes essentially fully transparent). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
