Poor quality font rendering

John Hendrikx hjohn at xs4all.nl
Wed Aug 28 16:47:25 PDT 2013

On 27/08/2013 17:59, Felipe Heidrich wrote:
> Hi John
> Thank you for the images!
> Comparing DirectWrite versus T2K for grayscale text the main difference that jumps at me is that in DirectWrite (which is what you get when prism.text=t2k is not set) the glyphs look a touch taller, looking somewhat stretched. Inspecting it closely you can see the actual pixel size is the same, it is the anti-aliasing at the top that is different.
> I'll see if anything can be done differently in DirectWrite to avoid this 'stretched' look, would that be better ?
The stretched look doesn't really bother me, it was just something that 
changed (the apparent height) that I couldn't put my finger on.  What 
botheres me more is that the bolded glyphs (especially the "2")  look 
wierd, the thickness of parts of the same glyph seems to vary (not just 
the "2" is affected, more glyphs look a touch worse, especially in the 
top bar in my first screenshot: 
http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png -- the legs of 
the M and H for example have different thickness.. the "2" jumps out though)

Whether those are result of the stretched look or not I cannot say.  I 
can also imagine that if you're using DirectWrite that there's little 
that can be done about it.  Are there any advantages of using DW over t2k?

> DirectWrite LCD for me is the one that gives the best result. That said, that is something wrong going on in the text over the progress bar.
Yes, DirectWrite LCD certainly looks crisp, unfortunately I cannot use 
it as my target is not an LCD screen.

I think however I know now what causes the text bug in the progress 
bar.  It's not really a progress bar, but just memory bar with text on 
it that's supposed to be readable no matter what using an inversion 
effect... It's this effect that I suspect causes problems with the 
tricks used for LCD rendering, as a simple inversion of LCD rendered 
glyphs is probably not gonna give the desired smooth result.

It's basically this, a Rectangle (with some CSS styling) and a Label in 
a StackPane.  The BlendMode.DIFFERENCE is what I suspect is causing the 
issue.  If so, LCD rendering may have to be disabled in these cases:

   private final Rectangle memoryBar = new Rectangle();
   private final Label memText = new Label();

   private final StackPane gc = new StackPane() {{
     getStyleClass().addAll("element", "memory");

     getChildren().add(new StackPane() {{
       getChildren().addAll(memoryBar, memText);



> Is it possible to run the same test case on Mac ? (Grayscale text, prism.text=t2k *not* set).
Unfortunately, I donot own a mac, and can't easily borrow one at this time.


> Regards
> Felipe
> On Aug 22, 2013, at 12:54 PM, John Hendrikx wrote:
>> On 22/08/2013 17:38, Felipe Heidrich wrote:
>>> John, for the sake of testing.
>>> Could you enable LCD text for the plot Label in your app ?
>>> Please let me know if that improves the position of each glyph (relative to one another).
>>> You should also try your app using our previous text rasterizer, run with -Dprism.text=t2k
>>> Is that better for you ?
>> Sure, I've created approximately the same shots with different settings for comparison:
>> prism.lcdtext=false
>> http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png
>> prism.lcdtext=true
>> http://ukyo.xs4all.nl/LCDSmoothed.png
>> prism.lcdtext=true, prism.text=t2k
>> http://ukyo.xs4all.nl/LCDSmoothedT2K.png
>> prism.lcdtext=false, prism.text=t2k
>> http://ukyo.xs4all.nl/GrayscaleT2K.png
>> Now that I compared them all, the last one is how it was for the longest time.  Now I also noticed that in the last shot the font height is a pixel smaller, which is one the changes I couldn't put my finger on.
>> The LCD smoothed versions look quite good, but (as you can see in screenshot 2) it for same reason garbles my memory indicator when the background image is fading in.  After the fade-in completes, the text is correct (I screenshotted it just before the fade-in completes to show the garbled text).  This occurs with both the normal and t2k renderer when LCD text is on.
>> So, to make it clear:
>> 1) Grayscale only: some glyphs look akward when bolded
>> 2) Grayscale only + t2k: this is how I expected it to be (I tuned the look for that).  Apparently this default has changed(?).  The font in the top bar seems to be 1 pixel less high then in all the other version.
>> 3) LCD only: Looks quite good on my normal LCD screens (better than Windows in my opinion, but perhaps the light-on-dark vs dark-on-light is the cause of that)
>> 4) LCD only + t2k: Also looks good, I think (3) looks better though
>> 3+4 fail when I drag the Window to my projector.  Colored fringes are visible.  This is probably a driver problem as Windows may not realize that my Projector is not using LCD (DLP projector).  I'm not sure how JavaFX figures this out, but I assume it asks Windows for this information.
>> --John
>>> Regards,
>>> Felipe
>>> On Aug 22, 2013, at 7:05 AM, John Hendrikx wrote:
>>>> Those are all normal controls, the plot section is just a Label for example.
>>>> On 22/08/2013 13:39, John C. Turnbull wrote:
>>>>> John H, it may be just me but pretty much *all* the fonts in your screenshot
>>>>> look quite poor and noticeably different from native font rendering.  If you
>>>>> look for instance at the text in the "Plot" section, to me that text looks
>>>>> awful.
>>>>> Is that inside a WebView or some other control?
>>>>> -jct
>>>>> -----Original Message-----
>>>>> From: openjfx-dev-bounces at openjdk.java.net
>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of John Hendrikx
>>>>> Sent: Thursday, 22 August 2013 17:29
>>>>> To: openjfx-dev at openjdk.java.net
>>>>> Subject: Re: Poor quality font rendering
>>>>> I took another good look, and I see what is bothering me is mostly how the
>>>>> glyph "2" is rendered on my system (it has a thick appearing curve attached
>>>>> to the base).  I've included a screenshot of my application that uses
>>>>> several different sizes fonts, but it seems only the ones in the top bar are
>>>>> rendered somewhat wierd.
>>>>> http://ukyo.xs4all.nl/Digit2RenderedPoorlyInTopBar.png
>>>>> I'm on Windows 7, JavaFX 8b99, 32-bit, using D3D pipeline (I get this stuff
>>>>> in log in an infinite loop, so must be D3D I think):
>>>>> D3D Vram Pool: 129,613,674 used (48.3%), 129,613,674 managed (48.3%),
>>>>> 268,435,456 total                   --
>>>>> com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:134)
>>>>> 75 total resources being
>>>>> managed
>>>>> -- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:153)
>>>>> 4 permanent resources
>>>>> (5.3%)
>>>>> -- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:154)
>>>>> 2 resources locked
>>>>> (2.7%)
>>>>> -- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:156)
>>>>> 43 resources contain interesting data
>>>>> (57.3%)                                                             --
>>>>> com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:158)
>>>>> 0 resources disappeared
>>>>> (0.0%)
>>>>> -- com.sun.prism.impl.ManagedResource.printSummary(ManagedResource.java:160)
>>>>> I also have this in main, before Application.launch is called:
>>>>>       System.setProperty("prism.lcdtext", "false");
>>>>> In .root in CSS I have:
>>>>>     -fx-font-family: "Arial";
>>>>>     -fx-font-size: 16px;
>>>>>     -fx-font-weight: normal;
>>>>> So all the fonts you see should be Arial (but the sizes and weights are
>>>>> tweaked depending on location).
>>>>> --John
>>>>> On 21/08/2013 20:51, Felipe Heidrich wrote:
>>>>>> John H:
>>>>>> In JFX we decided to go with sub-pixel positioned text (as opposite to
>>>>> pixel grid aligned).
>>>>>> That said, on Windows for grayscale text, we are not doing that (yet). Are
>>>>> you running Windows, with D3D pipeline ?
>>>>>> I would need to see a picture to be sure I understand the problem you
>>>>> describe.
>>>>>> Felipe
>>>>>> On Aug 21, 2013, at 10:19 AM, John Hendrikx wrote:
>>>>>>> I think I also noticed a change in font rendering around b99 somewhere...
>>>>> the fonts seem to be thinner than before, or perhaps more poorly aligned
>>>>> with pixel boundaries.  I'd prefer glyphs laid out in the same way each
>>>>> time, ie. letters are always on a new pixel boundary, so the same letter
>>>>> will look the same regardless of what preceeds it.  I have LCD rendering
>>>>> turned off as I donot appreciate colored fringes on my glyphs.
>>>>>>> On 21/08/2013 14:53, John C. Turnbull wrote:
>>>>>>>> I have only really tested JavaFX extensively on Windows so my
>>>>>>>> comments here apply mainly to that platform.
>>>>>>>> It seems that even with a font smoothing type of LCD, font rendering
>>>>>>>> in JavaFX is not at the same level of quality of native
>>>>>>>> applications.  My current experiences are with JavaFX 8 b103 and I
>>>>>>>> find that all rendered text in JavaFX appears of a significantly
>>>>>>>> poorer quality than that which I would see in Word for example or
>>>>>>>> even in IE10 (which I believe uses the same text rendering engine).
>>>>> Also, these observations are based on text in "standard"
>>>>>>>> controls and the quality of font rendering is dramatically worse
>>>>>>>> within the Canvas control.
>>>>>>>> I am not an expert in font technology but I have read many times
>>>>>>>> that the levels of antialiasing for text that can be achieved in a
>>>>>>>> GPU-based renderer are always going to be less than that achieved in a
>>>>> CPU-based renderer.
>>>>>>>> This is often explained on the basis of graphics card drivers being
>>>>>>>> optimised for performance and the rapid rendering of triangles
>>>>>>>> commonly required in games rather than for rendering quality when it
>>>>> comes to text.
>>>>>>>> Is this the reason why JavaFX font rendering appears less legible
>>>>>>>> and of a lower quality than native apps?
>>>>>>>> If so, how does IE10 for example achieve a higher quality of
>>>>>>>> rendering when it seems to also use DirectWrite?
>>>>>>>> Is the quality of JavaFX font rendering ever going to improve?
>>>>>>>> Thanks,
>>>>>>>> -jct

More information about the openjfx-dev mailing list