On Mon, 31 Aug 2026 18:05:21 GMT, Phil Race <[email protected]> wrote:
> > I wonder if the results depend on the user preferences, settings -> > > Personalization -> Fonts -> Adjust ClearType text. You go through a bunch > > of screens choosing the best looking one each time, though I have no idea > > what it does. I dug around in some Skia blogs and the consensus was that most users don't go through this process so it's crucial to come up with defaults that work well out of the box. That's also necessary on Linux. In any case it adjusts the following rendering params: - The EnhancedContrast level which, well, adjusts the contrast. You can see how the curve is applied in this PR. - The ClearType level which dictates whether you use 100% ClearType, 100% grayscale, or something in between. - The gamma. I'm not entirely sure this is adjusted by the user or derived from the display. I have a personal animosity toward this settings since I run in a VM and Windows tends to assign a gamma of 1.8 to virtual monitors which is incorrect. I'm not sure why; my best guess is that it's the ancient default gamma for Mac displays that Apple hasn't use in years. In any case I'm not entirely sure what it means to obey this gamma when you're putting pixels into a buffer that will be interpreted as sRGB by the monitor and further on in the FX rendering stack. > For ClearType, I am almost 100% sure that DW will do essentially the same > thing as GDI, although perhaps with different defaults. It really depends on the rendering mode used to generate the LCD mask. NATURAL and NATURAL_SYMMETRIC produce very different results from GDI_SYMMETRIC. If we really want to get darker text in FX I think we'd have to switch to GDI_SYMMETRIC. > This means that if FX does the rendering (it does) it needs to know what the > system default / user preference is for 'gamma'. I think contrast and ClearType level are probably more important (though in truth I haven't played with this much). And I would treat them as a pair, not pick up one without the other. > A bit of googling points me to CreateMonitorRenderingParams() which gives > you a IDWriteRenderingParams. Yeah, if we want to follow those params we should be pulling them from the factory. > I don't see FX using these APIs and perhaps it should so that it follows what > the rest of the system would do. [That may not result in text that a > particular user (say Martin) prefers, but it would be the best default for > the platform]. I recall the Skia folks weren't all that thrilled with the defaults. I'll see if I can track that down. > What's in the glyph cache ought to be 'linear', unfiltered, and the filtering > is applied during rendering to the destination surface. The DW NATURAL (etc) > settings are applied in creating the cached glyph, and aren't used in final > rendering. > > So I can't be 100% sure but would be surprised if the tuner UI affected what > is used in creating the cached glyph. >From what I can tell you're right, the tuner only affects the final render and >not the cached glyph creation. For what it's worth this PR does the whole goody-two-shoes conversion into and out of linear space in large part because I used to work for a company that took this sort of thing very, very seriously. I certainly can't do this for the grayscale path and don't intend to try. For grayscale I just want to verify which DirectWrite mode D2D is using under the hood and try to tweak the rendering so white-on-color text doesn't get so thin. Doing linear compositing with uncorrected sRGB colors tends to thicken black-on-white text and that not necessarily a bad thing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2284#issuecomment-5483219997
