Pivot
  1. Pivot
  2. PIVOT-393

Certain UI components do not properly respect system text anti-aliasing hints

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:
      None

      Description

      Some components render text using the drawString() method of Graphics2D and properly set the text rendering hints using the getTextAntialiasingHint() method in the Platform class. However, other components use a glyph vector that does not currently respect the text rendering hints. These components should be updated to use a FontRenderContext containing the correct text rendering hints:

      http://java.sun.com/javase/6/docs/api/java/awt/font/FontRenderContext.html#FontRenderContext(java.awt.geom.AffineTransform,%20java.lang.Object,%20java.lang.Object)

      Also, there is a minor issue with the use of getTextAntialiasingHint(): the AWT "awt.font.desktophints" property may contain multiple hints (e.g. on my desktop it also defines KEY_TEXT_LCD_CONTRAST) and Pivot is only looking at KEY_TEXT_ANTIALIASING. Additional methods should be added to support the other values.

        Issue Links

          Activity

          Hide
          Dirk Moebius added a comment -

          sets correct FontRendererContext

          Show
          Dirk Moebius added a comment - sets correct FontRendererContext
          Hide
          Dirk Moebius added a comment -

          I stumbled about the same issue when I noticed that Pivot's font rendering differed from Swing's. The reason is that Pivot uses a FontRenderContext with antiAlias always on instead of using the default system rendering hints. On my desktop with a LCD with subpixel rendering this lead to uglier results.

          The attached patch resolves this issue, but not the minor one regarding KEY_TEXT_LCD_CONTRAST.

          Show
          Dirk Moebius added a comment - I stumbled about the same issue when I noticed that Pivot's font rendering differed from Swing's. The reason is that Pivot uses a FontRenderContext with antiAlias always on instead of using the default system rendering hints. On my desktop with a LCD with subpixel rendering this lead to uglier results. The attached patch resolves this issue, but not the minor one regarding KEY_TEXT_LCD_CONTRAST.
          Hide
          Sandro Martini added a comment -

          Hi,
          just made some tests on Windows XP (32 bit) with Java 6 Update 19 as requested by Greg (http://n3.nabble.com/Re-jira-Updated-PIVOT-393-Certain-UI-components-do-not-properly-respect-system-text-anti-aliasing-his-td718307.html#a718307 ).

          In attach you can find some screenshots of before the patch and after the patch.

          To me sounds solved (in some cases text seems a little too defocused, but on higher resolutions probably this is a visually better result). In a few days I'll make also some tests on Windows 7 (64 bit) with higher resolution screen.

          Bye,
          Sandro

          Show
          Sandro Martini added a comment - Hi, just made some tests on Windows XP (32 bit) with Java 6 Update 19 as requested by Greg ( http://n3.nabble.com/Re-jira-Updated-PIVOT-393-Certain-UI-components-do-not-properly-respect-system-text-anti-aliasing-his-td718307.html#a718307 ). In attach you can find some screenshots of before the patch and after the patch. To me sounds solved (in some cases text seems a little too defocused, but on higher resolutions probably this is a visually better result). In a few days I'll make also some tests on Windows 7 (64 bit) with higher resolution screen. Bye, Sandro
          Hide
          Sandro Martini added a comment -

          My Tests on Windows XP with Java 6 Update 19, before and after the patch.

          Show
          Sandro Martini added a comment - My Tests on Windows XP with Java 6 Update 19, before and after the patch.
          Hide
          Greg Brown added a comment -

          I just attached some additional screen shots. To me, the "before" version actually looks a little better (more like what I see on the Mac). But maybe that's not what Windows users prefer.

          What's odd is that TextInput and TextArea don't appear to anti-alias the text in the "after" version. I think we'll need to resolve that (or at least understand why that is happening) before I can commit the patch.

          Show
          Greg Brown added a comment - I just attached some additional screen shots. To me, the "before" version actually looks a little better (more like what I see on the Mac). But maybe that's not what Windows users prefer. What's odd is that TextInput and TextArea don't appear to anti-alias the text in the "after" version. I think we'll need to resolve that (or at least understand why that is happening) before I can commit the patch.
          Hide
          Sandro Martini added a comment -

          From what I remember, some week ago I've done some tests on Windows 7 and an higher resolution, but text was too thin (less readable) ... I'll try the "after" from your link this evening (or max tomorrow night), and I'll tell you what happens there (maybe attaching other screenshots). So can you wait my tests before change the "after" demo form your link ? Thanks.

          Bye,
          Sandro

          Show
          Sandro Martini added a comment - From what I remember, some week ago I've done some tests on Windows 7 and an higher resolution, but text was too thin (less readable) ... I'll try the "after" from your link this evening (or max tomorrow night), and I'll tell you what happens there (maybe attaching other screenshots). So can you wait my tests before change the "after" demo form your link ? Thanks. Bye, Sandro
          Hide
          Greg Brown added a comment -

          I don't have any plans to take the before/after demos down.

          Show
          Greg Brown added a comment - I don't have any plans to take the before/after demos down.
          Hide
          Dirk Moebius added a comment -

          @Sandro: in your screenshots it seems that "before" you had no AA at all, and "after" you have soft-AA without subpixel rendering. Do you have an LCD?

          @Greg: IMHO the "after" version looks better in your screenshots. The text looks more clear to me, not frayed, especially the bold fonts. It is strange that TextArea is not AAed in your case; it works on my desktop (and in Sandro's version, too, apparently).

          Show
          Dirk Moebius added a comment - @Sandro: in your screenshots it seems that "before" you had no AA at all, and "after" you have soft-AA without subpixel rendering. Do you have an LCD? @Greg: IMHO the "after" version looks better in your screenshots. The text looks more clear to me, not frayed, especially the bold fonts. It is strange that TextArea is not AAed in your case; it works on my desktop (and in Sandro's version, too, apparently).
          Hide
          Sandro Martini added a comment -

          Hi to all,

          > I don't have any plans to take the before/after demos down.
          very good , so i can make other tests

          > @Sandro: in your screenshots it seems that "before" you had no AA at all, and "after" you have soft-AA without subpixel rendering. Do you have an LCD?
          Yes, I have an LCD , with default settings (both on Win XP and in Windows 7 and here I'll make some screenshots as soon as possible)

          Show
          Sandro Martini added a comment - Hi to all, > I don't have any plans to take the before/after demos down. very good , so i can make other tests > @Sandro: in your screenshots it seems that "before" you had no AA at all, and "after" you have soft-AA without subpixel rendering. Do you have an LCD? Yes, I have an LCD , with default settings (both on Win XP and in Windows 7 and here I'll make some screenshots as soon as possible)
          Hide
          Greg Brown added a comment -

          Dirk, what OS type/version and Java version are you using?

          Show
          Greg Brown added a comment - Dirk, what OS type/version and Java version are you using?
          Hide
          Sandro Martini added a comment -

          Hi, just made other tests on my Windows 7 at 64 bit, with an LCD and resolution 1680x1050 at 32 bit, with dpi at 100%, using all defaults, and Java 6 Update 19 at 32 bit.

          In attach you can find some screenshots for comparison (before and after).
          Also here seems better the "after" patch version.

          Greg, now you can update working demos on your test site, so we can make other tests (if needed) ... thanks.

          Bye

          Show
          Sandro Martini added a comment - Hi, just made other tests on my Windows 7 at 64 bit, with an LCD and resolution 1680x1050 at 32 bit, with dpi at 100%, using all defaults, and Java 6 Update 19 at 32 bit. In attach you can find some screenshots for comparison (before and after). Also here seems better the "after" patch version. Greg, now you can update working demos on your test site, so we can make other tests (if needed) ... thanks. Bye
          Hide
          Dirk Moebius added a comment -

          @Greg: Windows XP SP3 32bit, Java 1.6.0u16, LCD dual head (two monitors) with 1280x1024, Cleartype enabled.

          Show
          Dirk Moebius added a comment - @Greg: Windows XP SP3 32bit, Java 1.6.0u16, LCD dual head (two monitors) with 1280x1024, Cleartype enabled.
          Hide
          Dirk Moebius added a comment -

          Attached screenshot of Greg's test applet.
          Environment: Windows XP SP3 32bit, Java 1.6.0 u16, Cleartype

          Show
          Dirk Moebius added a comment - Attached screenshot of Greg's test applet. Environment: Windows XP SP3 32bit, Java 1.6.0 u16, Cleartype
          Hide
          Mike added a comment -

          RHEL 5, JRE 1.6.0_16, 1280x1024 resolution

          Console output:
          Java Plug-in 1.6.0_16
          Using JRE version 1.6.0_16-b01 Java HotSpot(TM) Client VM

          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional text metrics mode
          KEY_TEXT_ANTIALIASING: Antialiased text mode
          KEY_FRACTIONALMETRICS: Default fractional te

          Show
          Mike added a comment - RHEL 5, JRE 1.6.0_16, 1280x1024 resolution Console output: Java Plug-in 1.6.0_16 Using JRE version 1.6.0_16-b01 Java HotSpot(TM) Client VM KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional text metrics mode KEY_TEXT_ANTIALIASING: Antialiased text mode KEY_FRACTIONALMETRICS: Default fractional te
          Hide
          Greg Brown added a comment -

          Hi Mike,
          That text looks good to me but I'm not a RH user. Can you confirm that the text looks correct for your system?
          Thanks,
          Greg

          Show
          Greg Brown added a comment - Hi Mike, That text looks good to me but I'm not a RH user. Can you confirm that the text looks correct for your system? Thanks, Greg
          Hide
          Mike added a comment -

          Screenshots showing old and new kitchen sink demos.

          Show
          Mike added a comment - Screenshots showing old and new kitchen sink demos.
          Hide
          Greg Brown added a comment -

          Todd, can you take a look at the checkbox/radio button clipping issue? So far, it only seems to happen in RHEL - however, maybe it can be reproduced in Fedora as well.

          Show
          Greg Brown added a comment - Todd, can you take a look at the checkbox/radio button clipping issue? So far, it only seems to happen in RHEL - however, maybe it can be reproduced in Fedora as well.
          Hide
          Dirk Moebius added a comment -

          Greg, the clipping issue on checkbox/radio in the KitchenSink demo can also be reproduced on Windows if you change the default font in TerraTheme_default.json from "Verdana 11" to "Microsoft Sans Serif 11".

          Show
          Dirk Moebius added a comment - Greg, the clipping issue on checkbox/radio in the KitchenSink demo can also be reproduced on Windows if you change the default font in TerraTheme_default.json from "Verdana 11" to "Microsoft Sans Serif 11".
          Hide
          Greg Brown added a comment -

          I fixed the clipping issue. It was caused by an attempt to align the button part of the checkbox and radio button to the renderer's baseline. The skins now simply vertically center the button and renderer. We may revisit the baseline alignment in a future update, but this should be OK for now.

          Show
          Greg Brown added a comment - I fixed the clipping issue. It was caused by an attempt to align the button part of the checkbox and radio button to the renderer's baseline. The skins now simply vertically center the button and renderer. We may revisit the baseline alignment in a future update, but this should be OK for now.
          Hide
          Sandro Martini added a comment -

          pivot_aa-tests_winXP_2010-04-15.zip

          Windows XP SP3 32bit, JRE 6 Update 19, LCD 1280x1024 at 32 bit, with ClearType off (standard), and on (cleartype).

          The output is best than before (text is more clear than previous tests).
          I'll re-test this new version as soon as possible again on Windows 7.

          Bye

          Show
          Sandro Martini added a comment - pivot_aa-tests_winXP_2010-04-15.zip Windows XP SP3 32bit, JRE 6 Update 19, LCD 1280x1024 at 32 bit, with ClearType off (standard), and on (cleartype). The output is best than before (text is more clear than previous tests). I'll re-test this new version as soon as possible again on Windows 7. Bye
          Hide
          Dirk Moebius added a comment -

          @Greg: does than mean that if a Label and a Checkbox/Radio is on one line in a form, they don't get baseline aligned?

          Show
          Dirk Moebius added a comment - @Greg: does than mean that if a Label and a Checkbox/Radio is on one line in a form, they don't get baseline aligned?
          Hide
          Greg Brown added a comment -

          No, it just means that, if your renderer defines a baseline, the actual checkbox square or radio button circle won't be baseline-aligned to the renderer within the button. The button will still be baseline-aligned in a container that supports baseline layout.

          I think we can revisit it later. I just wanted to make sure that it works correctly for the common case for now.

          Show
          Greg Brown added a comment - No, it just means that, if your renderer defines a baseline, the actual checkbox square or radio button circle won't be baseline-aligned to the renderer within the button. The button will still be baseline-aligned in a container that supports baseline layout. I think we can revisit it later. I just wanted to make sure that it works correctly for the common case for now.
          Hide
          Dirk Moebius added a comment -

          Added screenshots for Ubuntu 9.10, Java 1.6.0-u16.
          Displays nicely; fonts look more clear now, especiall bold fonts.

          Show
          Dirk Moebius added a comment - Added screenshots for Ubuntu 9.10, Java 1.6.0-u16. Displays nicely; fonts look more clear now, especiall bold fonts.
          Hide
          Daniel added a comment -

          Looking at the new Kitchen Sink demo posted by Greg (http://ixnay.biz/PIVOT-393/kitchen-sink.html) checkboxes and radio buttons are still using Gray AA instead of LCD AA.

          Show
          Daniel added a comment - Looking at the new Kitchen Sink demo posted by Greg ( http://ixnay.biz/PIVOT-393/kitchen-sink.html ) checkboxes and radio buttons are still using Gray AA instead of LCD AA.
          Hide
          Greg Brown added a comment -

          Hi Daniel,
          What platform are you on? Can you post a screen shot, ideally one that includes a comparison between Pivot and native text?
          Thanks,
          Greg

          Show
          Greg Brown added a comment - Hi Daniel, What platform are you on? Can you post a screen shot, ideally one that includes a comparison between Pivot and native text? Thanks, Greg
          Hide
          Daniel added a comment -

          I'm on Windows XP, but the same thing can be noticed in the kitchensink-ubuntu9.zip screenshots, so it's not platform specific. In the GrayscaleRadioText screenshot (400% zoom) you can see that most of the text uses LCD AA. You'll see that the LCD AA text is composed of multi-colored pixels (blue, orange, red, yellow, etc) for black text. Then you'll notice that the text for radio buttons is composed only of grayscale pixels (black and shades of gray) which is just the good ol' Grayscale AA. Similarly, checkboxes also use Grayscale AA. All other components that I checked look good - they use LCD AA as expected.

          Show
          Daniel added a comment - I'm on Windows XP, but the same thing can be noticed in the kitchensink-ubuntu9.zip screenshots, so it's not platform specific. In the GrayscaleRadioText screenshot (400% zoom) you can see that most of the text uses LCD AA. You'll see that the LCD AA text is composed of multi-colored pixels (blue, orange, red, yellow, etc) for black text. Then you'll notice that the text for radio buttons is composed only of grayscale pixels (black and shades of gray) which is just the good ol' Grayscale AA. Similarly, checkboxes also use Grayscale AA. All other components that I checked look good - they use LCD AA as expected.
          Hide
          Greg Brown added a comment -

          Quite right. This was happening because the checkbox and radio button text is drawn using a Label, which uses a GlyphVector internally. The glyph vector is created using the correct AA hints, but then when rendered it was being anti-aliased again by the checkbox and radio button skin classes.

          This is fixed for Checkbox and RadioButton, but the same problem may exist elsewhere in the code. If you see other occurrences, I would appreciated it if you would add them here.

          Show
          Greg Brown added a comment - Quite right. This was happening because the checkbox and radio button text is drawn using a Label, which uses a GlyphVector internally. The glyph vector is created using the correct AA hints, but then when rendered it was being anti-aliased again by the checkbox and radio button skin classes. This is fixed for Checkbox and RadioButton, but the same problem may exist elsewhere in the code. If you see other occurrences, I would appreciated it if you would add them here.

            People

            • Assignee:
              Greg Brown
              Reporter:
              Greg Brown
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development