Re: [JAVA2D] Bug in rendering text under JDK 6.0
Okay, now that's just weird. :| Garbling happens under WinXP as well. It seems to be related to LCD text settings. For as far as my limited testing took me, enabling ClearType will garble the second line. As soon as it is enabled/disabled (no need to reload/recompile), the second line changes. Did some further testing: could it be that the wrong pixels are taking for AlphaComposite? I have the impression that the pixels drawn onto the screen are really just test but with each pixel repeated three times: [code] +++ + x + +x+ + x + + x + + x + + xx+ +++ == +++ + + + xxx + + + +x+ +x+ +x+ + + +++ [/code] Changing the LCD orientation (horizontal to vertical) also changes the pixel's positions, but they seem to have correct horizontal spacing, hence. In the horizontal case, if we could just take each third pixel, we'd get test back, I believe. [Message sent by forum member 'tarbo' (tarbo)] http://forums.java.net/jive/thread.jspa?messageID=225069 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Bug in rendering text under JDK 6.0
It is completely cross-platform. Looks like a case where I forgot to ask that the text pipes be re-validated. I think it may be as little as a one line fix for setComposite to set a flag that some font rendering settings need to be re-validated. I see Igor filed bug 6576507 for your test. Its probable that there's a workaround of setting some other hint at the same time that will tickle the re-validation. -phil [EMAIL PROTECTED] wrote: Okay, now that's just weird. :| Garbling happens under WinXP as well. It seems to be related to LCD text settings. For as far as my limited testing took me, enabling ClearType will garble the second line. As soon as it is enabled/disabled (no need to reload/recompile), the second line changes. Did some further testing: could it be that the wrong pixels are taking for AlphaComposite? I have the impression that the pixels drawn onto the screen are really just test but with each pixel repeated three times: [code] +++ + x + +x+ + x + + x + + x + + xx+ +++ == +++ + + + xxx + + + +x+ +x+ +x+ + + +++ [/code] Changing the LCD orientation (horizontal to vertical) also changes the pixel's positions, but they seem to have correct horizontal spacing, hence. In the horizontal case, if we could just take each third pixel, we'd get test back, I believe. [Message sent by forum member 'tarbo' (tarbo)] http://forums.java.net/jive/thread.jspa?messageID=225069 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Bug in rendering text under JDK 6.0
Its probable that there's a workaround of setting some other hint at the same time that will tickle the re-validation. I'd be very interested in a workaround. I was thinking about rendering the second text into a temporary image. Should work (if that would be the first text rendered there), but i'm worried about the performance hit - creating an image every time i need to paint the text of a button / toggle button / radio button / checkbox / ... Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=225089 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Bug in rendering text under JDK 6.0
I'd be very interested in a workaround. There's probably several things that will work, but something as simple as this does the trick for me, and will be fairly cheap. // if this line is removed, everything is OK graphics.setComposite(AlphaComposite.getInstance( AlphaComposite.SRC_OVER, 0.6f)); Font font = graphics.getFont(); font = font.deriveFont(font.getStyle(), font.getSize2D()); graphics.setFont(font); graphics.drawString(test, 10, 80); it works because even though the font is the same as before, the implementation treats it as simpler to simply set the new font (since its not == the old one), and re-validate. Since you need to revalidate anyway here, nothing is lost there. -phil [EMAIL PROTECTED] wrote: Its probable that there's a workaround of setting some other hint at the same time that will tickle the re-validation. I'd be very interested in a workaround. I was thinking about rendering the second text into a temporary image. Should work (if that would be the first text rendered there), but i'm worried about the performance hit - creating an image every time i need to paint the text of a button / toggle button / radio button / checkbox / ... Thanks Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=225089 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Bug in rendering text under JDK 6.0
Font font = graphics.getFont(); font = font.deriveFont(font.getStyle(), font.getSize2D()); graphics.setFont(font); Thanks. I'll try it when i get home. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=225098 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Java2D anti alias rounded corner fidelity problems
Hi Mikael, [EMAIL PROTECTED] wrote: I don't know what to say. You go to great length explaining why circles aren't round and why the corner radius on rounded rectangles are different on the different sides, and why you will not fix it. I guess other platforms (Flash, .NET and similar) also have these problems since they aren't fixable? Actually, I wasn't sure - I just know that the rendering models that we use are fairly industry standard and there are well-known techniques for working around them, some can be implemented as heuristics within the rendering engine (along with a way to turn them off since they aren't always right) and we've done that, and others have to be implemented as care in how one constructs rendering requests. I know that we've exercised about as much magic as we know how to exercise internally here in the implementation in the heuristics we created for path normalization, but I believe there could be more magic, it just isn't something we have sitting in our back pocket and it can't be summoned up on command like a bug fix normally can. This isn't a case of whoops, we forgot to increment that variable or we should probably keep more bits of resolution here, this is a limitation of how advanced a set of heuristics we know how to create. And, like I said, I wasn't totally sure about Flash - but I went and downloaded it and played around with it for a few hours and discovered that, basically, they use a rendering model that is fairly close to what we've implemented - very close to the industry standard. If you render small circles with Flash you get fuzzy outlines on the circles. If you enable their form of stroke hinting then you get lopsided un-round (but still fuzzy) circles. At least in our case I believe the circles tend to be crisp (or at least our heuristics try to keep them crisp) even though they are lop-sided. The hinted circles I saw with Flash were neither crisp nor were they round. I then tried a few more experiments and found that many of the issues that people complain about with respect to Java2D rendering are exactly the behaviors that Flash produces (and they have some problems that we don't as well). I haven't done the same experiment with .NET, but in either case - if you have output from some other rendering engine that does what you want then please share a real-world example, rather than guessing about the other platforms. It turns out that it is too hard to do Java2D graphics in a high fidelity way, at least without resorting to hacks. And are you sure that it is possible with other systems? I'd like to see some examples. Another problem I have is that one can not in Java2D in a generic way outline and fill a Shape and make it look good. The outline will plot outside and inside the shape depending on the direction of the vector (in degrees). This is since you don't provide an INSIDE and OUTSIDE stroke. You have the hanging right/left stroke and the pure stroke. Flash provides a very similar rendering model. When you draw 1 pixel wide strokes at 1:1 scales you get the same hanging pen strokes that we render. The pure stroke isn't usable since you either get the lines sharing two pixels for vertical and horizontal lines or you do as you suggest and translate 0.5, in which case you get good lines but shapes that are one pixel too big. You get the one pixel too big problem with Flash too. The stroke follows the outline and straddles the path - therefore the stroked version will always be linewidth larger than the filled stroke. One CAN solve the one-pixel-too-big-shapes-when-using-PURE-and-translate.5-problem by scaling the output with ((width - 1.0)/width) but that only works for rectangles (shapes with equal but mirrored quadrants actually, so also for circles) but fails for general paths, polygons and composite shapes of all kinds. Scaling the output isn't a very general solution and can be tricky to get right with oblong shapes - even if they are convex - as you say. Other techniques for handling stroking involve things like: - stroke then fill (even widths == symmetric border) (odd widths and STROKE_NORMAL == uneven border) (odd widths and PURE == fuzzy symmetric border in AA) - fill then stroke (misalignment of stroke at odd sizes is hidden behind the stroke) - use linewidth=2x and stroke then fill (gives a 1 pixel outer/halo stroke, but needs a fill to carve out the stroke) - use linewidth=2x and compute [strokeShape SUB Shape] (gives a 1 pixel outer stroke shape) - use linewidth=2x and intersect strokeShape and Shape (gives a 1 pixel inner stroke shape) This problem has shown to unsolvable in a generic way. Only if one has prior knowledge about what type of shape to paint and are in full control of the rendering hints can one get good results for some types of shapes. You can not create
Re: [JAVA2D] Bug in rendering text under JDK 6.0
Thanks for the suggested workaround. Works good and the text is no longer garbled. Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=225149 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
