I’ve entered a bug on this https://bugs.openjdk.org/browse/JDK-8389632.
DirectWrite can produce distorted LCD characters for some fonts at specific sizes. JavaFX chooses a rendering mode when initializing the text analysis (see createAnalysis in DWGlyph.java) and the current NATURAL rendering mode can produce some truly ugly glyphs. The problem is most noticeable on the horizontal stems. None of the other rendering modes have the same problem. See the bug report for screenshots comparing NATURAL with NATURAL_SYMMETRIC. The problem is at its worst at specific pixel sizes. For example, Tahoma looks bad when the lower-case letters are around 10 pixels high. For a screen scaling factor of 150% that means Tahoma is visibly degraded at around 12 points and Segoe UI has less noticeable issues at 13 points. Higher screen scaling factors will push the problem to lower point sizes. Next up: I want to better understand how the code is dealing with sRGB gamma. From what I can tell the grayscale path is applying linear grayscale values to (non-linear) sRGB colors and then compositing the results in (non-linear) sRGB space. If true that would skew the pixels darker. But this is not an area of the code I’m familiar with so I might be mistaken or it might not matter in the end. Martin > On Jul 29, 2026, at 1:39 PM, Philip Race <[email protected]> wrote: > > You touch on another point that is part of the subjective aspect. > From the beginning there were some people who were not keen on DirectWrite's > LCD font > rendering (as used by FX) and preferred the older GDI LCD font rendering > (used by Swing), > but the platform direction was DW .. but yes, now it apparently has so many > directions I don't know what is "THE" direction. > And its not just grayscale vs LCD, there's hinting (and what exact hinting ?) > vs unhinted. > > Some of it may be guided by use case. Like (as I wrote) FX using unhinted > grayscale. > > -phil. > > > On 7/29/26 1:04 PM, Martin Fox wrote: >> Before choosing a default JavaFX needs to ensure both antialiasing >> approaches work as well as they can. >> >> I was able to reproduce the original issue by drawing a capital “O” in >> MinSanLatin-Heavy at 20 points using LCD smoothing. On Win11 this glyph is >> being drawn poorly but the same glyph on Linux looks fine. This looks like a >> problem with Microsoft’s glyph rendering quality. I’m not sure there’s >> anything we can do to get DirectWrite to produce better results but it’s >> worth a look. >> >> On Linux letter spacing with grayscale smoothing is not good. I think this >> is related to some problems I investigated a couple of years ago; one part >> of the JavaFX text system was doing sub-pixel rendering but some part of the >> glyph caching machinery didn’t match it. I’ll go see if I can retrieve the >> details on that and write up a bug. >> >> Normally I’m inclined to follow the platform’s lead but in this case >> Microsoft is all over the map on grayscale vs. ClearType. In Win11 the Start >> menu seems to be using grayscale only but Edge and File Explorer use >> grayscale in some areas and ClearType in others. File names on the desktop >> use ClearType. No clear winner there. >> >> Martin >> >> > On Jul 29, 2026, at 12:27 PM, Philip Race <[email protected]> >> > <mailto:[email protected]> wrote: >> > >> > Oh .. at least 10 years ago, but the basis for those decisions has not >> > changed. >> > >> > -phil >> > >> > On 7/29/26 10:08 AM, Christopher Schnick wrote: >> >> For the sake of completeness , how long ago were those decisions made and >> >> the objections raised? On 29/07/2026 18: 30, Philip Race wrote: > > LCD >> >> is only the default on controls. Grayscale is the default > everywhere >> >> else. > > >> >> For the sake of completeness , how long ago were those decisions made >> >> and the objections raised? >> >> >> >> On 29/07/2026 18:30, Philip Race wrote: >> >> > >> >> > LCD is only the default on controls. Grayscale is the default > >> >> > everywhere else. >> >> > >> >> > Unhinted greyscale was a requirement to be able to do smooth animations. >> >> > But there were lots of objections to the poor quality that resulted on >> >> > > controls, >> >> > particularly on windows where users expect it as that is the windows > >> >> > norm. >> >> > So LCD was required to be the default on controls. >> >> > >> >> > On mac where Apple did away with LCD, if you have a non-retina > >> >> > display, text is not good (IMO). >> >> > >> >> > For every person who thinks it is better, there'll be someone else who >> >> > > passionately disagrees. >> >> > So unless there's a 100% sure-fire way to enable this only on "hidpi" > >> >> > displays, I'd vote against it being the *default*. >> >> > >> >> > -phil. >> >> > >> >> > On 7/29/26 7:42 AM, Andy Goryachev wrote: >> >> >> Fully agree with John here. The only concern is the backward >> >> >> >> compatibility - any existing application that uses it will appear >> >> >> >> slightly different. >> >> >> >> >> >> I would support changing the default (and mentioning it in the >> >> >> >> release notes). >> >> >> >> >> >> -andy >> >> >> >> >> >> >> >> >> From: John Hendrikx <[email protected]> >> >> >> <mailto:[email protected]> >> >> >> Date: Wednesday, July 29, 2026 at 03:13 >> >> >> To: [email protected] <mailto:[email protected]> >> >> >> <[email protected]> <mailto:[email protected]> >> >> >> Subject: Re: [External] : Re: Enable grayscale antialiasing by >> >> >> >> default on Windows HiDPI displays? >> >> >> >> >> >> My 2 cents; LCD rendering (like cleartype) was never good and more a >> >> >> marketing gimmick than anything else. On high DPI displays you don't >> >> >> need it, and on low DPI displays it just result in ugly colored fringes >> >> >> on characters. This is so noticeable to me that even on very high DPI >> >> >> displays it is the first thing I turn off on any new install. No need >> >> >> for clown letters when grayscale smoothing is perfectly fine. >> >> >> >> >> >> In FX, it also the first thing I disable, no matter what the scaling or >> >> >> monitor DPI. >> >> >> >> >> >> Since the time of low DPI screens is rapidly becoming ancient history, >> >> >> I >> >> >> wouldn't be against changing the default to be grayscale. >> >> >> >> >> >> --John >> >> >> >> >> >> On 28/07/2026 23:54, Marius Hanl wrote: >> >> >>> From what I saw and understand, -fx-font-smoothing-type: gray; is >> >> >>> indeed a better default. >> >> >>> I think this is a topic worth to discuss. >> >> >>> >> >> >>> -- Marius >> >> >>> >> >> >>> Am 27.07.2026 um 20:23 schrieb Christopher Schnick: >> >> >>>> I think most devs do not see this as a large issue as you have >> >> >>>> >>>> the >> >> >>>> ability to fix it with the property (or also >> >> >>>> -fx-font-smoothing-type: >> >> >>>> gray in css) You are right, the default font rendering settings >> >> >>>> are not >> >> >>>> the best, but JavaFX is not really >> >> >>>> >> >> >>>> >> >> >>>> I think most devs do not see this as a large issue as you have the >> >> >>>> ability to fix it with the property (or also -fx-font-smoothing-type: >> >> >>>> gray in css) >> >> >>>> >> >> >>>> You are right, the default font rendering settings are not the >>>> >> >> >>>> best, but >> >> >>>> JavaFX is not really known for having optimal default settings out of >> >> >>>> the box in general. If you want to get something good out of it, you >> >> >>>> have to do some work. >> >> >>>> >> >> >>>> I can submit a PR to change the defaults, no idea whether that will >> >> >>>> be >> >> >>>> accepted though. >> >> >>>> >> >> >>>> On 21/07/2026 18:31, Glavo wrote: >> >> >>>>> Hey, does anyone care about this? >> >> >>>>> >> >> >>>>> On Wed, Jun 3, 2026 at 12:31 PM Glavo <[email protected]> >> >> >>>>> <mailto:[email protected]> wrote: >> >> >>>>> >> >> >>>>>> Hi everyone, >> >> >>>>>> >> >> >>>>>> We have noticed that, for JavaFX applications on Windows HiDPI >> >> >>>>>> displays, >> >> >>>>>> subpixel antialiasing often produces very poor rendering results >> >> >>>>>> for many >> >> >>>>>> fonts. >> >> >>>>>> >> >> >>>>>> For example, when using the MiSans font on a display scaled to >> >> >>>>>> 150%, the >> >> >>>>>> edges of English letters rendered with subpixel antialiasing show >> >> >>>>>> >>>>>> very >> >> >>>>>> noticeable jagged artifacts: >> >> >>>>>> >> >> >>>>>> https://imgur.com/ZpzDWZ5 >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> For Chinese text, the results of subpixel antialiasing are even >> >> >>>>>> more >> >> >>>>>> disastrous. Many strokes either blur together or show obvious >> >> >>>>>> inconsistencies in thickness, making the text look very poor. >> >> >>>>>> >> >> >>>>>> To address this issue, we tried forcing grayscale font >>>>>> >> >> >>>>>> antialiasing by >> >> >>>>>> adding -Dprism.lcdtext=false. After testing many fonts, we found >> >> >>>>>> that on >> >> >>>>>> HiDPI displays, grayscale antialiasing is never worse than subpixel >> >> >>>>>> antialiasing, and it fixes rendering issues for many fonts. On >> >> >>>>>> non-HiDPI >> >> >>>>>> displays, that is, at 100% scaling, grayscale antialiasing and >> >> >>>>>> subpixel >> >> >>>>>> antialiasing each have their own advantages and disadvantages. >> >> >>>>>> >> >> >>>>>> We then added a workaround in our application: on Windows, if the >> >> >>>>>> primary >> >> >>>>>> screen scale is greater than 100%, the application automatically >> >> >>>>>> adds the >> >> >>>>>> JVM option -Dprism.lcdtext=false to enable grayscale antialiasing. >> >> >>>>>> After a >> >> >>>>>> year of real-world use, we have not received any user complaints >> >> >>>>>> about this >> >> >>>>>> strategy. >> >> >>>>>> >> >> >>>>>> I hope JavaFX can provide a built-in mechanism for automatically >> >> >>>>>> selecting >> >> >>>>>> the appropriate antialiasing algorithm, so that users do not have >> >> >>>>>> to adjust >> >> >>>>>> these options manually. >> >> >>>>>> >> >> >>>>>> Glavo >> >> >>>>>> >> >> >>>> References >> >> >>>> >> >> >>>> Visible links: >> >> >>>> >> >> >>>> Hidden links: >> >> >>>> 2. >> >> >>>> https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!N_27VmluMChEtbPqF3n0OJaftfpglPBNZejHqzzeFb1qS8N4hxQV99OhWoOMiGeeVh8EC5YpXT4UkOvvvJnbNWukdBqco00DuJbtzA$ >> >> >>>> >>>> >> >> > >> >
