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]> 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]> >> >> Date: Wednesday, July 29, 2026 at 03:13 >> >> To: [email protected] <[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]> 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$ >> >>>> >>>> >> >
