Better text rendering in Chromium-based browsers on Windows

Original Article ↗ Hacker News Discussion ↗

Perceived visual change

  • Many commenters initially couldn’t see a difference in the blog’s scaled image; at 1:1 resolution the “after” text is clearly darker/higher contrast for most people.
  • Some describe the new rendering as sharper and more readable; others see it as slightly bolder or blurrier and more tiring.
  • A minority find the old text “unreadably blurry,” while some say they preferred the lighter pre-change look.
  • The change is noticeable on a range of displays (1080p, 1440p, OLED, phones), but how “better” it looks is highly subjective.

Windows vs other platforms

  • Several people say Chrome/Chromium text on Windows has long looked worse than Firefox and native apps.
  • Some think Windows overall has the worst font rendering, especially for CJK; others argue it’s a matter of taste (Windows prioritizing crispness vs Apple/macOS prioritizing faithful shapes).
  • Linux and macOS are discussed as having their own quirks; high-DPI helps everywhere but low-DPI is still common.

Technical details: Skia, DirectWrite, ClearType

  • Chromium uses DirectWrite for lookup/shaping but Skia for rasterization, so it historically ignored ClearType’s gamma/contrast settings.
  • The fix: Skia/Chromium now read ClearType Tuner values and align defaults with Windows’ own text contrast and gamma.
  • Skia dependents can now configure text gamma/contrast via SkSurfaceProps.
  • There is debate over GDI vs DirectWrite and “correct” rendering of specific fonts (e.g., Verdana) compared to Word/LibreOffice.

Subpixel AA, OLED, and DPI

  • Subpixel AA on OLED and non-standard subpixel layouts is a major unresolved pain point; ClearType doesn’t match many OLED panels.
  • Some argue grayscale AA would be fine at modern PPIs; others counter that low-/mid-PPI monitors (1080p, 1440p, big office displays) still dominate and need subpixel AA.
  • Discussion covers exotic subpixel layouts, potential algorithms, EDID support, and the complexity introduced by decades of hinting tuned to classic ClearType.

“Correct” rendering vs readability

  • Commenters note there’s no single objective definition of “correct” font rendering: pure grayscale sampling of outlines vs hinting/darkening for readability.
  • Trade-offs depend on resolution, pixel layout, and human perception; font rendering is framed as choosing compromises that “offend the least people.”

Process, timelines, and priorities

  • Some are frustrated it took roughly four years from initial experiments to shipping a fix for such a core feature.
  • Others argue that most time goes into design, validation, OS-integration, and user research rather than “writing code,” and that text-rendering bugs are hard to report and change safely.
  • There is disagreement over whether OS-consistent text rendering should have been a release blocker for Chromium-based Edge, versus a low-priority visual inconsistency.

Impact on designers and ecosystem

  • Some worry that designers previously hand-tuned font weights/colors around Chromium’s “washed-out” rendering and may see layouts shift.
  • Response: the web is inherently not pixel-perfect; browser behavior can and will change, and designers should not depend on exact rasterization details.
  • Non-browser Skia users historically inherited Chromium’s “washed out” text; this change partially remedies that.