Christopher, I’m looking into it. Expect a PR soon.
Martin > On Aug 20, 2026, at 11:58 AM, Christopher Schnick <[email protected]> wrote: > > So what is the conclusion of this discussion so far? In terms of the next > steps. > > I take it you guys see potential for fixes/optimizations to improve the > existing font rendering, so the font smoothing type default should not be > changed yet? > > On 03/08/2026 23:06, Philip Race wrote: >> I vaguely remember there was some question over NATURAL vs NATURAL_SYMMETRIC >> when this work was first done. >> But I don't remember the arguments for either with any clarity or certainty. >> It is possible that NATURAL works better on lower-resolution LCD devices >> when using ClearType mode. >> it may be another case where what to use should take into account the >> environment in which it will be rendered. >> >> I'm rather surprised to learn we do any gamma correction on greyscale text. >> It *may* be a mistake if it is being done. >> And leaving aside text entirely, I am not aware that the rendering pipeline >> explicitly applies gamma correction anywhere. >> Not saying it doesn't, but I'm not aware of it. >> >> LCD sub-pixel text does require something that "looks" like gamma correction. >> But it isn't looking at any display color response information. >> It is just a fudge number largely to reduce the color fringing of LCD >> sub-pixel text. >> So that's what we do .. or should be doing .. And JDK applies the same >> technique in Java 2D for Swing text. >> >> -phil >> >> On 8/3/26 8:58 AM, Martin Fox wrote: >>> 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 >>> 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]> >>>>> > 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$ >>>>> >> >>>> >>>> >>>>> >> > >>>>> >>>> >>>
