10 ms·

Better text rendering in Chromium-based browsers on Windows

174 points by barlog 2y ago

WhereIsTheTruth 2y ago
Chromium on linux has a similar issue, white text / dark background, very noticeable on low DPI 1080p screens You can instantly notice it when you try to read comments on youtube (w/ dark theme)
vlovich123 2y ago
I feel like the before/after picture is a prank. I can’t tell a difference, at least looking at it on my iPad.
- ahartmetz 2y ago
  The text looks fatter / darker on the right
- tiffanyh 2y ago
  If you look at the non-highlighted black text, in the new version - the text is darker. I agree it's minor, but it's definitely darker. https://developer.chrome.com/static/blog/better-text-rendering-in-chromium-based-browsers-on-windows/cleartext_1920.png https://developer.chrome.com/static/blog/better-text-renderi... Note: I'm not affiliated to Chromium in any way.
  - megaman821 2y ago
    Embedding that image in a blog where it has to be resized down is silly since it makes the change impossible to see. At full size I can easily see the difference between the two though.
    - rbanffy 2y ago
      Resampling the image made the comparison essentially impossible. The 1:1 version makes it perfectly clear.
- seanalltogether 2y ago
  The text is just higher contrast, if you pull out a color dropper tool or zoom way in on the text you can see the after image has darker text
- deleted 2y ago
  [deleted]
- asadkn 2y ago
  It's a very subtle difference but noticeable in the anti-aliasing. I don't have Windows right now, so I haven't tested if the change's closer to Firefox - but Firefox always had some heavy antialiasing on Windows, which I wasn't a fan of.
- do_not_redeem 2y ago
  To me the one on the right looks slightly darker/bolder, but not qualitatively better. The stems on the letter "m" in "<meta" in lines 2 and 4 are badly hinted (smeared/mushy looking), and drawn differently even though they're in the same horizontal position in both lines.
  - rvnx 2y ago
    Yeah the new version looks bolder or more blurry, slightly more tiring to read
- scarface_74 2y ago
  https://news.ycombinator.com/item?id=42655870 https://news.ycombinator.com/item?id=42655870
- eviks 2y ago
  Visible on a phone, though the why is not clearly seen because that's not how you compare such poor quality pics - you need to flip back & forth, preferably zoomed (a common fail of most of these kind of blogs is not to do that). Then you can see the deficiencies on the left and the reason why it's so thin - in letters like 'i' the vertical bar is semi-transparent, not solid
- cbg0 2y ago
  Right side looks slightly better on a 1440p 27" oled, text has better contrast.
- paulirish 2y ago
  https://imgsli.com/MzQ4OTEw https://imgsli.com/MzQ4OTEw A before/after image slider. Sadly, not pixel perfect, but a small upgrade for comparison UX.
  - rvnx 2y ago
    Looked better before I guess
- jcelerier 2y ago
  wild, it's obvious to me even in miniature and even more at 1x size, and I don't even have my glasses on
- rendaw 2y ago
  Whoah, for me the left looks unreadably blurry... but it sounds like that's only me? If other people saw it I have a hard time believing they wouldn't mention such a significant difference and just talk about "I stems" instead.
rafram 2y ago
I had noticed this in Chrome, and it always irked me! I definitely can see the difference.
xnx 2y ago
Pretty cool story of mainline Chrome benefiting from changes implemented in Edge.
- ttoinou 2y ago
  Probably both Google and Microsoft poured resources into this
rho4 2y ago
I was missing some info about subpixel anti-aliasing (ClearType) and Low- vs Hi-DPI screens.
alternatetwo 2y ago
Chromium can't render fonts at all after they got rid of GDI rendering. Just compare Verdana 12pt in Word/LibreOffice and Chrome, they're not seriously trying to tell me that's the correct font? The letters don't even look the same. Left is Firefox with GDI, right is Chrome: https://i.redd.it/0fk50cgcexie1.png https://i.redd.it/0fk50cgcexie1.png
- dist-epoch 2y ago
  Firefox does not use GDI, it used DirectWrite which is GPU accelerated.
  - kevingadd 2y ago
    Historically Firefox did have a GDI fallback for certain fonts specifically to address this user complaint, in order to make them look "right". I don't know when/if it was removed. The pref name is 'gfx.font_rendering.cleartype_params.force_gdi_classic_for_families'. I believe it may have just enabled a GDI compatibility mode for DirectWrite, but I'm not sure if that uses the GDI rasterizer under the hood or not.
  - alternatetwo 2y ago
    It most certainly uses GDI for Verdana. Firefox tried to disable that by overwriting the previous default setting for gfx.font_rendering.cleartype_params.force_gdi_classic_for_families and gfx.font_rendering.cleartype_params.force_gdi_classic_max_size, but restoring them fixed that. Also this is not important. What's important is that DirectWrite does not render this font correctly, if you compare it with LibreOffice or Word.
    - e4m2 2y ago
      It just uses GDI_CLASSIC for DWRITE_MEASURING_MODE [1] and DWRITE_RENDERING_MODE [2] in that case. No actual GDI in sight. [1] https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_measuring_mode https://learn.microsoft.com/en-us/windows/win32/api/dcommon/... [2] https://learn.microsoft.com/en-us/windows/win32/api/dwrite/ne-dwrite-dwrite_rendering_mode https://learn.microsoft.com/en-us/windows/win32/api/dwrite/n...
FAAST 2y ago
I’ll have to look closer into Skia but DirectWrite is text API par excellence.
- DaiPlusPlus 2y ago
  > DirectWrite is text API par excellence. One has to only look at the... storied (to say the least) history of Microsoft's first-party 2D graphics/text APIs to see it took a lot of iteration to get to this point; and it leaves me wondering when the next inflection on the learning curve will be released... Meanwhile, GDI will somehow still live-on.
  - rbanffy 2y ago
    I bet it can still render .FON files. Even the non-bitmap, plotter-like ones.
barlog 2y ago
Skia <https://skia.org https://skia.org>
zokier 2y ago
One of those things that to me is frustrating is how there is no clear unambiguous definition of what is correct in font rendering. Presumably typeface designers have some specific intent on how heavy strokes and stems are, but then that somehow becomes ambiguous when a font gets rendered on screen. Asking for user feedback feels kinda pointless in that context, does your average user know what some random font should look like? Better would be to ask type designers for feedback on rendering their own typefaces
- crazygringo 2y ago
  There is actually a definition of what is correct, and I'm pretty sure Adobe Photoshop does it in one of its modes. It's just pure grayscale antialiasing of the underlying letterform, with the correct gamma used by the monitor. Or subpixel rendering if you want, as long as it matches your screen's actual LCD layout. The issue is that that's not necessarily what's most readable. So various forms of hinting and darkening can be introduced to improve readability, and all of that is of course entirely subjective.
  - eviks 2y ago
    Since readability is the most important factor in the area of text design, your definition of correct that goes against that is incorrect
- groby_b 2y ago
  Vastly oversimplified, that'd be because fonts are individual strokes of varying width and free layout that get rendered on a array of pixels with fixed sizes and fixed layout. Resampling comes with some aliasing/information loss. Font rendering is about picking which losses you're willing to take. And you can't just "ask designers" because the trade-offs are different based on resolution and pixel layout. And they change as you scale the font up and down. ("Font hinting" tries to fix issues with that scaling. It's got its own downsides) And because it's fun, there's also a perception component, where different people can just look at the same font and process it differently. Font rendering is the art of making compromises that offend the least amount of people. A good starting point on the subject: "Text rendering hates you" - https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ (I could swear there was also a great post by Raph Levien, but I can't find it)
Oarch 2y ago
Funny, yesterday I noticed this and thought "huh, it's like the text got a bit sharper" and then immediately dismissed it as something I must have made up...
rhodescolossus 2y ago
That's really great news. I always wondered why text rendering in Chrome looked so much worse than Firefox.
- rbanffy 2y ago
  Is it my impression or text rendering on Windows is just worse than on other platforms?
  - exusn 2y ago
    It's worse. Windows aggressively alters the shape and overall character of fonts to perform anti-aliasing, making them appear sharper on low-DPI displays. Linux is a goofy with this too, but still looks better than Windows. macOS handles it best on high-DPI displays, but because subpixel anti-aliasing is no longer used, fonts can be a little blurry on low-DPI displays. Also, https://tonsky.me/blog/monitors/ https://tonsky.me/blog/monitors/
  - kevingadd 2y ago
    It's partly a matter of taste, I know people who prefer it. But historically Apple has paid the most attention to high-quality text rendering and Windows' approach has been... utilitarian, with stuff like ClearType mostly optimized for 'crispness' and detail at the expense of actually looking good consistently, IMO.
  - kccqzy 2y ago
    It is a matter of personal preference. I personally love the look when there is no hinting at all, even though this means blurriness at the pixel level. Windows prioritizes crispness. I hate that and I think it looks worse. On the other hand, back in Mac OS X Leopard, the OS lets you adjust the level of font smoothing. I preferred the strongest level of smoothing. Many designers hate that because it is akin to faux bold. I didn't like that Apple removed it in Snow Leopard. These days it hardly matters though.
hnra 2y ago
Are these defaults part of Skia or Chromium, i.e. will all Skia dependents benefit from this change?
- KurtCS 2y ago
  Developer here. These changes impacted both Chromium and Skia. Skia dependents can now configure their text gamma and contrast values via SkSurfaceProps - https://skia-review.googlesource.com/c/skia/+/798096 https://skia-review.googlesource.com/c/skia/+/798096
  - hnra 2y ago
    Thanks for the info!
calebh 2y ago
It would be great if we could also go ahead and fix subpixel anti-aliasing for OLED screens. People have been been trying for years to get Microsoft's attention about this issue. [1] The subpixel layout of OLED screens is different than the the traditional layout, so text ends up looking pretty bad. Patching ClearType would be the first step to fixing this issue. I'm surprised that none of the display manufacturers have tried twisting Microsoft's arm to fix this issue. At the present moment OLED screens are the superior display technology, but cannot be used for productivity because of this issue. [1]: https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595
- kevin_thibedeau 2y ago
  They should just ditch ClearType and use grayscale AA like Acrobat used to have. PPI is high enough on modern displays that the reduction in resolution won't matter.
  - kevingadd 2y ago
    The linked issue points out that grayscale AA has color fringing on some of the subpixel layouts. It's not obvious to me how one would fix it though, it seems like a deficiency built-in to panels with weird subpixel layouts and the subpixel layouts are a compromise chosen to achieve (fake?) higher PPI
  - wtallis 2y ago
    > PPI is high enough on modern displays that the reduction in resolution won't matter. Have you looked at the desktop monitor market recently? There are still a lot of models that are not substantially higher PPI than what was normal 20 years ago. PCPartPicker currently shows 1333 monitors in-stock across the stores it tracks. Of those, only 216 have a vertical resolution of at least 2160 pixels (the height of a 4k display). Zero of those 4k monitors are smaller than 27", so none of them are getting close to 200 PPI. On the low-PPI side of things, there are 255 models with a resolution of 2560x1440 and a diagonal size of at least 27". One standard size and resolution combination that was common over a decade ago still outnumbers the entirety of the high-PPI market segment. If you look at the Steam Hardware Survey results, their statistics indicate an even worse situation, with over half of gaming users still stuck at 1920x1080. If subpixel antialiasing made sense during the first decade after LCDs replaced CRT, then it still matters today.
pbw 2y ago
Their experiments started in 2021 and the change was made in 2025? This makes me think AI writing code for us will only speed things up so much.
- asadotzler 2y ago
  Do you genuinely believe those 4 years were spent writing code? This is why wet behind the ears tech boys can't be trusted any more. They really think that the hardest part of software, the thing that slows us down, is writing code. Really!? Kid, I'll offer you some free advice. Writing the code is the least difficult part. Deciding what and how to write (and what not to bother with) is a critical step that has nothing to do with writing code. Designing the architecture, ensuring it's correct, leaving something well written and maintainable for the next grunt, documenting code so it's easy to understand and to review, ensuring your code supports all the desired use cases and interactions with users and other code/apps/etc, iterating on it until it's polished, and then actually maintaining it and fixing bugs that are inevitably going to be there if the code is sufficiently expansive. Those are just a few of the things that aren't "grinding code" as you want to make software. Read a programming book for Pete's sake, and stop assuming you can just fake it till you make it because you are part of what's destroying software for the world and it's got to stop.
  - rbanffy 2y ago
    The kid will learn. It always takes time.
whalesalad 2y ago
Windows has the worst font rendering of all time. Baby steps, I guess? The difference is marginal.
- AraceliHarker 2y ago
  Windows font rendering, especially for CJK characters, remains problematic even with the transition from Skia to DirectWrite. Fine-tuning the ClearType tuner doesn't achieve the same text weight as MacType; the characters still appear too thin. Moreover, Microsoft's choice of UI fonts is also poor.
feverzsj 2y ago
Chrome's font rendering issue on Windows has been known for more than a decade. Turns out all you need to do is reading proper gamma/contrast values from register. But they didn't fix it in Skia, so most Skia based projects still have shitty font rendering on Windows. Here is the meta issue tracker: https://issues.chromium.org/issues/40037626 https://issues.chromium.org/issues/40037626
- martinsnow 2y ago
  If i understand correctly, chrome is using windows own font rendering capabilities which should be the preferred method?
  - ygra 2y ago
    Only for shaping and measuring, if I recall correctly. Rendering is still done by Skia and not DirectWrite.
    - martinsnow 2y ago
      Yes you're correct. My memory is a bit fuzzy but it the fact is in the article > While Skia uses DirectWrite on Windows for certain functionality such as font lookup, the final text rasterization is actually handled directly by Skia. And one major factor in the "washed out" feedback from users is the internal contrast and gamma settings for text rendering. > Two main differences in text contrast and gamma values were uncovered between Edge's Chromium-based engine and its prior engine. First, Skia does not pick up text contrast and gamma values from the Windows ClearType Tuner. Secondly, it uses different default values for text contrast and gamma than those used by Edge's DirectWrite-based text stack. I was debugging blurry text in windows at a previous job where we used electron to develop a softphone application and could not understand why the lighter text was harder to read on windows. That would settle the debate. I hope they will come up with better integration with windows so these differences will disappear.
BearOso 2y ago
> After a lot of user research, members of both Edge and Chromium determined that a contrast value of 1.0 closely matched the text rendering of pre-Chromium Edge and looked consistent compared to other native Windows applications. So they decided that not deliberately lowering contrast will fix the contrast problem. So this basically stems from that annoying designer trend of grey text on grey backgrounds that was in turn based on the false assumption that our displays have infinite contrast.
mrpippy 2y ago
My overriding feeling after reading this is: displaying text is a key job of a web browser. A browser that showed no text would be useless. And yet, after learning that Chromium's text looked wrong on Windows (by far the most important platform for Edge and Chrome), it took 4 years for the Chromium and/or Edge teams to fix it. 4 years of user research? 3 years to respect the user's ClearType Tuner values? Being a regression from pre-Chromium Edge, this should have been a release blocker on Chromium-based Edge. Instead, text looked bad for 4 years.
- jgneff 2y ago
  That's actually pretty fast. It took 10 years for Java[1] and 5 years for JavaFX[2] to fix some trivial but rather severe text rendering bugs. Most of that time was getting enough courage to fix them myself. :-) Reporting text rendering bugs is frustratingly difficult! [1] https://github.com/jgneff/openjdk-freetype https://github.com/jgneff/openjdk-freetype [2] https://github.com/javafxports/openjdk-jfx/issues/229 https://github.com/javafxports/openjdk-jfx/issues/229
- wtallis 2y ago
  To an unfortunately large degree, browsers and browser engines are simply not concerned with respecting the host platform's defaults and conventions. The browsers are here to replace (and reinvent) the host platforms, not integrate with them. Developers writing apps to run in a browser engine are more likely to care about their app looking the same across all devices and operating systems, even if their users may care more about the app following the same conventions as other apps on their platform of choice. Edge getting this wrong is embarrassing for Microsoft, but is not at all surprising when you take into account how notoriously fractious Microsoft is and how unlikely it is that anyone in Microsoft could enforce a cohesive vision for UI standards to the extent of being able to make this a release blocker for Edge.
- crazygringo 2y ago
  > Being a regression from pre-Chromium Edge, this should have been a release blocker on Chromium-based Edge. Instead, text looked bad for 4 years. Text didn't look bad. It just didn't look identical to the rest of the OS. It's not obvious why that should be a blocker at all, rather than a low-priority inconsistency. And for people who switch between devices all day long but use the same browser, you could even argue that it's more important for text rendering to be consistent in a browser across devices, rather than consistent within a device. I don't personally think that, but I can see why there might discussion over whether this is even an issue at all, much less a blocking one.
egnehots 2y ago
What about all the designers that used to handle this issue by tweaking their font weights, colors...? Changing a long standing issue with a lot of users will break things for some people (using edge, with an eyes for these details..)
- wtallis 2y ago
  Web designers must simply accept that they are working in a medium that is not amenable to (sub)pixel-perfect reproducibility. It is not—and never has been—safe to assume that future versions of a given browser will render identically to the current one. It is not safe to assume that the browsers you are fine-tuning for will remain popular in the future. It is not safe to assume that other users with the same browser version (or a browser claiming to be the same version) as you are using will get an identical rendering as you get on your system. As a web designer, you must accept that the browser is fundamentally not yours to control. It is an agent acting on behalf of the user, not on behalf of you.
dbcooper 2y ago
Perhaps they can fix the extreme slope angle of italics on some sites next.
Whomever6342 2y ago
Why does Chromium need to manually set default contrast/gamma values instead of just reading Windows' default ClearType values? The article mentions they added support for reading ClearType Tuner values last year, so why aren't the Windows defaults available through the same API? Seems unnecessarily complex to maintain separate defaults.
- KurtCS 2y ago
  Developer of this feature and author of the blog post here. Good questions and I can elaborate. As you mentioned, Chromium does read ClearType Tuner values and passes them on to Skia them if they're set (I implemented this behavior last year). However, most users don't run the ClearType Tuner. This announcement is basically that we are now using values that match the default ClearType contrast and gamma. There's no extra complexity or separate defaults. This behavior shipped later because it has a much larger impact on the user base. This wasn't happening automatically because Chromium doesn't user DirectWrite for text rasterization, so they were missing default Windows behaviors like the ClearType Tuner integration and Windows default values.
peterburkimsher 2y ago
The text rendering looks much better now! Would the same teams at Google be interested in implementing better line breaking? The Japanese text in the screenshot in the article breaks words in half. There's a library that does it already; it just needs adding to Chromium: https://github.com/google/budoux/ https://github.com/google/budoux/
eviks 2y ago
> One piece of feedback was significant—many Edge users shared that text appeared "washed out" and that it didn't look consistent with text in other parts of Windows. > Text looked washed out on Chrome on Windows pre-132. > The team took this feedback seriously and did some investigation. Wait, does "the team" have no eyes/visual tests of their own? How can you seriously make a claim about them taking it seriously when they failed to notice this degradation in the first place? Or, for that matter, that it took so long to fix > It was evident that the text contrast value needed to increase, but data was needed to determine how much to adjust it. No, you adjust first until it's not "evident" anymore and then waste years on consumer research
- nasretdinov 2y ago
  Well, software engineers don't have that great vision usually...
chris_pie 2y ago
Might be worth noting that Chromium seems to only use subpixel rendering on high-constrast text. I've also seen sites that don't use it for some other unknown reason, for example Microsoft Teams.

174 points by barlog 2y ago

Chromium on linux has a similar issue, white text / dark background, very noticeable on low DPI 1080p screens You can instantly notice it when you try to read comments on youtube (w/ dark theme)

vlovich123 2y ago

I feel like the before/after picture is a prank. I can’t tell a difference, at least looking at it on my iPad.

ahartmetz 2y ago
The text looks fatter / darker on the right
tiffanyh 2y ago
If you look at the non-highlighted black text, in the new version - the text is darker. I agree it's minor, but it's definitely darker. https://developer.chrome.com/static/blog/better-text-rendering-in-chromium-based-browsers-on-windows/cleartext_1920.png https://developer.chrome.com/static/blog/better-text-renderi... Note: I'm not affiliated to Chromium in any way.
- megaman821 2y ago
  Embedding that image in a blog where it has to be resized down is silly since it makes the change impossible to see. At full size I can easily see the difference between the two though.
  - rbanffy 2y ago
    Resampling the image made the comparison essentially impossible. The 1:1 version makes it perfectly clear.
seanalltogether 2y ago
The text is just higher contrast, if you pull out a color dropper tool or zoom way in on the text you can see the after image has darker text
deleted 2y ago
[deleted]
asadkn 2y ago
It's a very subtle difference but noticeable in the anti-aliasing. I don't have Windows right now, so I haven't tested if the change's closer to Firefox - but Firefox always had some heavy antialiasing on Windows, which I wasn't a fan of.
do_not_redeem 2y ago
To me the one on the right looks slightly darker/bolder, but not qualitatively better. The stems on the letter "m" in "<meta" in lines 2 and 4 are badly hinted (smeared/mushy looking), and drawn differently even though they're in the same horizontal position in both lines.
- rvnx 2y ago
  Yeah the new version looks bolder or more blurry, slightly more tiring to read
scarface_74 2y ago
https://news.ycombinator.com/item?id=42655870 https://news.ycombinator.com/item?id=42655870
eviks 2y ago
Visible on a phone, though the why is not clearly seen because that's not how you compare such poor quality pics - you need to flip back & forth, preferably zoomed (a common fail of most of these kind of blogs is not to do that). Then you can see the deficiencies on the left and the reason why it's so thin - in letters like 'i' the vertical bar is semi-transparent, not solid
cbg0 2y ago
Right side looks slightly better on a 1440p 27" oled, text has better contrast.
paulirish 2y ago
https://imgsli.com/MzQ4OTEw https://imgsli.com/MzQ4OTEw A before/after image slider. Sadly, not pixel perfect, but a small upgrade for comparison UX.
- rvnx 2y ago
  Looked better before I guess
jcelerier 2y ago
wild, it's obvious to me even in miniature and even more at 1x size, and I don't even have my glasses on
rendaw 2y ago
Whoah, for me the left looks unreadably blurry... but it sounds like that's only me? If other people saw it I have a hard time believing they wouldn't mention such a significant difference and just talk about "I stems" instead.

rafram 2y ago

I had noticed this in Chrome, and it always irked me! I definitely can see the difference.

xnx 2y ago

Pretty cool story of mainline Chrome benefiting from changes implemented in Edge.

ttoinou 2y ago
Probably both Google and Microsoft poured resources into this

rho4 2y ago

I was missing some info about subpixel anti-aliasing (ClearType) and Low- vs Hi-DPI screens.

alternatetwo 2y ago

Chromium can't render fonts at all after they got rid of GDI rendering. Just compare Verdana 12pt in Word/LibreOffice and Chrome, they're not seriously trying to tell me that's the correct font? The letters don't even look the same. Left is Firefox with GDI, right is Chrome: https://i.redd.it/0fk50cgcexie1.png https://i.redd.it/0fk50cgcexie1.png

dist-epoch 2y ago
Firefox does not use GDI, it used DirectWrite which is GPU accelerated.
- kevingadd 2y ago
  Historically Firefox did have a GDI fallback for certain fonts specifically to address this user complaint, in order to make them look "right". I don't know when/if it was removed. The pref name is 'gfx.font_rendering.cleartype_params.force_gdi_classic_for_families'. I believe it may have just enabled a GDI compatibility mode for DirectWrite, but I'm not sure if that uses the GDI rasterizer under the hood or not.
- alternatetwo 2y ago
  It most certainly uses GDI for Verdana. Firefox tried to disable that by overwriting the previous default setting for gfx.font_rendering.cleartype_params.force_gdi_classic_for_families and gfx.font_rendering.cleartype_params.force_gdi_classic_max_size, but restoring them fixed that. Also this is not important. What's important is that DirectWrite does not render this font correctly, if you compare it with LibreOffice or Word.
  - e4m2 2y ago
    It just uses GDI_CLASSIC for DWRITE_MEASURING_MODE [1] and DWRITE_RENDERING_MODE [2] in that case. No actual GDI in sight. [1] https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_measuring_mode https://learn.microsoft.com/en-us/windows/win32/api/dcommon/... [2] https://learn.microsoft.com/en-us/windows/win32/api/dwrite/ne-dwrite-dwrite_rendering_mode https://learn.microsoft.com/en-us/windows/win32/api/dwrite/n...

FAAST 2y ago

I’ll have to look closer into Skia but DirectWrite is text API par excellence.

DaiPlusPlus 2y ago
> DirectWrite is text API par excellence. One has to only look at the... storied (to say the least) history of Microsoft's first-party 2D graphics/text APIs to see it took a lot of iteration to get to this point; and it leaves me wondering when the next inflection on the learning curve will be released... Meanwhile, GDI will somehow still live-on.
- rbanffy 2y ago
  I bet it can still render .FON files. Even the non-bitmap, plotter-like ones.

barlog 2y ago

Skia <https://skia.org https://skia.org>

zokier 2y ago

One of those things that to me is frustrating is how there is no clear unambiguous definition of what is correct in font rendering. Presumably typeface designers have some specific intent on how heavy strokes and stems are, but then that somehow becomes ambiguous when a font gets rendered on screen. Asking for user feedback feels kinda pointless in that context, does your average user know what some random font should look like? Better would be to ask type designers for feedback on rendering their own typefaces

crazygringo 2y ago
There is actually a definition of what is correct, and I'm pretty sure Adobe Photoshop does it in one of its modes. It's just pure grayscale antialiasing of the underlying letterform, with the correct gamma used by the monitor. Or subpixel rendering if you want, as long as it matches your screen's actual LCD layout. The issue is that that's not necessarily what's most readable. So various forms of hinting and darkening can be introduced to improve readability, and all of that is of course entirely subjective.
- eviks 2y ago
  Since readability is the most important factor in the area of text design, your definition of correct that goes against that is incorrect
groby_b 2y ago
Vastly oversimplified, that'd be because fonts are individual strokes of varying width and free layout that get rendered on a array of pixels with fixed sizes and fixed layout. Resampling comes with some aliasing/information loss. Font rendering is about picking which losses you're willing to take. And you can't just "ask designers" because the trade-offs are different based on resolution and pixel layout. And they change as you scale the font up and down. ("Font hinting" tries to fix issues with that scaling. It's got its own downsides) And because it's fun, there's also a perception component, where different people can just look at the same font and process it differently. Font rendering is the art of making compromises that offend the least amount of people. A good starting point on the subject: "Text rendering hates you" - https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ (I could swear there was also a great post by Raph Levien, but I can't find it)

Oarch 2y ago

Funny, yesterday I noticed this and thought "huh, it's like the text got a bit sharper" and then immediately dismissed it as something I must have made up...

rhodescolossus 2y ago

That's really great news. I always wondered why text rendering in Chrome looked so much worse than Firefox.

rbanffy 2y ago
Is it my impression or text rendering on Windows is just worse than on other platforms?
- exusn 2y ago
  It's worse. Windows aggressively alters the shape and overall character of fonts to perform anti-aliasing, making them appear sharper on low-DPI displays. Linux is a goofy with this too, but still looks better than Windows. macOS handles it best on high-DPI displays, but because subpixel anti-aliasing is no longer used, fonts can be a little blurry on low-DPI displays. Also, https://tonsky.me/blog/monitors/ https://tonsky.me/blog/monitors/
- kevingadd 2y ago
  It's partly a matter of taste, I know people who prefer it. But historically Apple has paid the most attention to high-quality text rendering and Windows' approach has been... utilitarian, with stuff like ClearType mostly optimized for 'crispness' and detail at the expense of actually looking good consistently, IMO.
- kccqzy 2y ago
  It is a matter of personal preference. I personally love the look when there is no hinting at all, even though this means blurriness at the pixel level. Windows prioritizes crispness. I hate that and I think it looks worse. On the other hand, back in Mac OS X Leopard, the OS lets you adjust the level of font smoothing. I preferred the strongest level of smoothing. Many designers hate that because it is akin to faux bold. I didn't like that Apple removed it in Snow Leopard. These days it hardly matters though.

hnra 2y ago

Are these defaults part of Skia or Chromium, i.e. will all Skia dependents benefit from this change?

KurtCS 2y ago
Developer here. These changes impacted both Chromium and Skia. Skia dependents can now configure their text gamma and contrast values via SkSurfaceProps - https://skia-review.googlesource.com/c/skia/+/798096 https://skia-review.googlesource.com/c/skia/+/798096
- hnra 2y ago
  Thanks for the info!

calebh 2y ago

It would be great if we could also go ahead and fix subpixel anti-aliasing for OLED screens. People have been been trying for years to get Microsoft's attention about this issue. [1] The subpixel layout of OLED screens is different than the the traditional layout, so text ends up looking pretty bad. Patching ClearType would be the first step to fixing this issue. I'm surprised that none of the display manufacturers have tried twisting Microsoft's arm to fix this issue. At the present moment OLED screens are the superior display technology, but cannot be used for productivity because of this issue. [1]: https://github.com/microsoft/PowerToys/issues/25595 https://github.com/microsoft/PowerToys/issues/25595

kevin_thibedeau 2y ago
They should just ditch ClearType and use grayscale AA like Acrobat used to have. PPI is high enough on modern displays that the reduction in resolution won't matter.
- kevingadd 2y ago
  The linked issue points out that grayscale AA has color fringing on some of the subpixel layouts. It's not obvious to me how one would fix it though, it seems like a deficiency built-in to panels with weird subpixel layouts and the subpixel layouts are a compromise chosen to achieve (fake?) higher PPI
- wtallis 2y ago
  > PPI is high enough on modern displays that the reduction in resolution won't matter. Have you looked at the desktop monitor market recently? There are still a lot of models that are not substantially higher PPI than what was normal 20 years ago. PCPartPicker currently shows 1333 monitors in-stock across the stores it tracks. Of those, only 216 have a vertical resolution of at least 2160 pixels (the height of a 4k display). Zero of those 4k monitors are smaller than 27", so none of them are getting close to 200 PPI. On the low-PPI side of things, there are 255 models with a resolution of 2560x1440 and a diagonal size of at least 27". One standard size and resolution combination that was common over a decade ago still outnumbers the entirety of the high-PPI market segment. If you look at the Steam Hardware Survey results, their statistics indicate an even worse situation, with over half of gaming users still stuck at 1920x1080. If subpixel antialiasing made sense during the first decade after LCDs replaced CRT, then it still matters today.

pbw 2y ago

Their experiments started in 2021 and the change was made in 2025? This makes me think AI writing code for us will only speed things up so much.

asadotzler 2y ago
Do you genuinely believe those 4 years were spent writing code? This is why wet behind the ears tech boys can't be trusted any more. They really think that the hardest part of software, the thing that slows us down, is writing code. Really!? Kid, I'll offer you some free advice. Writing the code is the least difficult part. Deciding what and how to write (and what not to bother with) is a critical step that has nothing to do with writing code. Designing the architecture, ensuring it's correct, leaving something well written and maintainable for the next grunt, documenting code so it's easy to understand and to review, ensuring your code supports all the desired use cases and interactions with users and other code/apps/etc, iterating on it until it's polished, and then actually maintaining it and fixing bugs that are inevitably going to be there if the code is sufficiently expansive. Those are just a few of the things that aren't "grinding code" as you want to make software. Read a programming book for Pete's sake, and stop assuming you can just fake it till you make it because you are part of what's destroying software for the world and it's got to stop.
- rbanffy 2y ago
  The kid will learn. It always takes time.

whalesalad 2y ago

Windows has the worst font rendering of all time. Baby steps, I guess? The difference is marginal.

AraceliHarker 2y ago
Windows font rendering, especially for CJK characters, remains problematic even with the transition from Skia to DirectWrite. Fine-tuning the ClearType tuner doesn't achieve the same text weight as MacType; the characters still appear too thin. Moreover, Microsoft's choice of UI fonts is also poor.

feverzsj 2y ago

Chrome's font rendering issue on Windows has been known for more than a decade. Turns out all you need to do is reading proper gamma/contrast values from register. But they didn't fix it in Skia, so most Skia based projects still have shitty font rendering on Windows. Here is the meta issue tracker: https://issues.chromium.org/issues/40037626 https://issues.chromium.org/issues/40037626

martinsnow 2y ago
If i understand correctly, chrome is using windows own font rendering capabilities which should be the preferred method?
- ygra 2y ago
  Only for shaping and measuring, if I recall correctly. Rendering is still done by Skia and not DirectWrite.
  - martinsnow 2y ago
    Yes you're correct. My memory is a bit fuzzy but it the fact is in the article > While Skia uses DirectWrite on Windows for certain functionality such as font lookup, the final text rasterization is actually handled directly by Skia. And one major factor in the "washed out" feedback from users is the internal contrast and gamma settings for text rendering. > Two main differences in text contrast and gamma values were uncovered between Edge's Chromium-based engine and its prior engine. First, Skia does not pick up text contrast and gamma values from the Windows ClearType Tuner. Secondly, it uses different default values for text contrast and gamma than those used by Edge's DirectWrite-based text stack. I was debugging blurry text in windows at a previous job where we used electron to develop a softphone application and could not understand why the lighter text was harder to read on windows. That would settle the debate. I hope they will come up with better integration with windows so these differences will disappear.

BearOso 2y ago

> After a lot of user research, members of both Edge and Chromium determined that a contrast value of 1.0 closely matched the text rendering of pre-Chromium Edge and looked consistent compared to other native Windows applications. So they decided that not deliberately lowering contrast will fix the contrast problem. So this basically stems from that annoying designer trend of grey text on grey backgrounds that was in turn based on the false assumption that our displays have infinite contrast.

mrpippy 2y ago

My overriding feeling after reading this is: displaying text is a key job of a web browser. A browser that showed no text would be useless. And yet, after learning that Chromium's text looked wrong on Windows (by far the most important platform for Edge and Chrome), it took 4 years for the Chromium and/or Edge teams to fix it. 4 years of user research? 3 years to respect the user's ClearType Tuner values? Being a regression from pre-Chromium Edge, this should have been a release blocker on Chromium-based Edge. Instead, text looked bad for 4 years.

jgneff 2y ago
That's actually pretty fast. It took 10 years for Java[1] and 5 years for JavaFX[2] to fix some trivial but rather severe text rendering bugs. Most of that time was getting enough courage to fix them myself. :-) Reporting text rendering bugs is frustratingly difficult! [1] https://github.com/jgneff/openjdk-freetype https://github.com/jgneff/openjdk-freetype [2] https://github.com/javafxports/openjdk-jfx/issues/229 https://github.com/javafxports/openjdk-jfx/issues/229
wtallis 2y ago
To an unfortunately large degree, browsers and browser engines are simply not concerned with respecting the host platform's defaults and conventions. The browsers are here to replace (and reinvent) the host platforms, not integrate with them. Developers writing apps to run in a browser engine are more likely to care about their app looking the same across all devices and operating systems, even if their users may care more about the app following the same conventions as other apps on their platform of choice. Edge getting this wrong is embarrassing for Microsoft, but is not at all surprising when you take into account how notoriously fractious Microsoft is and how unlikely it is that anyone in Microsoft could enforce a cohesive vision for UI standards to the extent of being able to make this a release blocker for Edge.
crazygringo 2y ago
> Being a regression from pre-Chromium Edge, this should have been a release blocker on Chromium-based Edge. Instead, text looked bad for 4 years. Text didn't look bad. It just didn't look identical to the rest of the OS. It's not obvious why that should be a blocker at all, rather than a low-priority inconsistency. And for people who switch between devices all day long but use the same browser, you could even argue that it's more important for text rendering to be consistent in a browser across devices, rather than consistent within a device. I don't personally think that, but I can see why there might discussion over whether this is even an issue at all, much less a blocking one.

egnehots 2y ago

What about all the designers that used to handle this issue by tweaking their font weights, colors...? Changing a long standing issue with a lot of users will break things for some people (using edge, with an eyes for these details..)

wtallis 2y ago
Web designers must simply accept that they are working in a medium that is not amenable to (sub)pixel-perfect reproducibility. It is not—and never has been—safe to assume that future versions of a given browser will render identically to the current one. It is not safe to assume that the browsers you are fine-tuning for will remain popular in the future. It is not safe to assume that other users with the same browser version (or a browser claiming to be the same version) as you are using will get an identical rendering as you get on your system. As a web designer, you must accept that the browser is fundamentally not yours to control. It is an agent acting on behalf of the user, not on behalf of you.

dbcooper 2y ago

Perhaps they can fix the extreme slope angle of italics on some sites next.

Whomever6342 2y ago

Why does Chromium need to manually set default contrast/gamma values instead of just reading Windows' default ClearType values? The article mentions they added support for reading ClearType Tuner values last year, so why aren't the Windows defaults available through the same API? Seems unnecessarily complex to maintain separate defaults.

KurtCS 2y ago
Developer of this feature and author of the blog post here. Good questions and I can elaborate. As you mentioned, Chromium does read ClearType Tuner values and passes them on to Skia them if they're set (I implemented this behavior last year). However, most users don't run the ClearType Tuner. This announcement is basically that we are now using values that match the default ClearType contrast and gamma. There's no extra complexity or separate defaults. This behavior shipped later because it has a much larger impact on the user base. This wasn't happening automatically because Chromium doesn't user DirectWrite for text rasterization, so they were missing default Windows behaviors like the ClearType Tuner integration and Windows default values.

peterburkimsher 2y ago

The text rendering looks much better now! Would the same teams at Google be interested in implementing better line breaking? The Japanese text in the screenshot in the article breaks words in half. There's a library that does it already; it just needs adding to Chromium: https://github.com/google/budoux/ https://github.com/google/budoux/

eviks 2y ago

> One piece of feedback was significant—many Edge users shared that text appeared "washed out" and that it didn't look consistent with text in other parts of Windows. > Text looked washed out on Chrome on Windows pre-132. > The team took this feedback seriously and did some investigation. Wait, does "the team" have no eyes/visual tests of their own? How can you seriously make a claim about them taking it seriously when they failed to notice this degradation in the first place? Or, for that matter, that it took so long to fix > It was evident that the text contrast value needed to increase, but data was needed to determine how much to adjust it. No, you adjust first until it's not "evident" anymore and then waste years on consumer research

nasretdinov 2y ago
Well, software engineers don't have that great vision usually...

chris_pie 2y ago

Might be worth noting that Chromium seems to only use subpixel rendering on high-constrast text. I've also seen sites that don't use it for some other unknown reason, for example Microsoft Teams.