text rendering using subpixel / cleartype

Use case

Using Flutter on Windows desktop I noticed the text rendering differs from other (native) Windows applications (including Chrome browser). I am using ClearType on my 'low-density' LCD monitor, as surely a lot of my clients do as well, and for me this reads text a lot better.

For text on buttons etc. this doesn't matter much, but for paragraphs of text the difference with other applications gets very noticable.

Proposal

Would it be possible marking specific textblocks/paragraphs to render it using the OS settings so it gets on par with other native applications?

@bungeman

According to @bungeman, we can fix this by specifying the pixel geometry when we set up our surface props.

We do that here: https://github.com/flutter/engine/blob/15ac210024105fbc8620aa81a2044f25e6a40b96/shell/gpu/gpu_surface_gl.cc#L173 (and a few other similar places for emedder/vulkan).

On Windows specifically, we can get the right type from https://docs.microsoft.com/en-us/dotnet/desktop/wpf/advanced/cleartype-registry-settings?view=netframeworkdesktop-4.8#registry-setting-1

This will probably require some kind of update to the embedder API so that the Windows embedding can specify this, so it can be set properly here: https://github.com/flutter/engine/blob/15ac210024105fbc8620aa81a2044f25e6a40b96/shell/platform/embedder/embedder.cc#L360

Oh, and one more piece: Skia may need an update so that we can use the kSubpixelAntialias enum when setting how to do antialiasing on the font.

@stuartmorgan

/cc @stuartmorgan - I believe this is a complaint that's been raised in other Windows contexts, he might know if this is a duplicate.

I'm goign to take a look at wiring the SkSurface param through for the embedding API

@stuartmorgan

/cc @stuartmorgan - I believe this is a complaint that's been raised in other Windows contexts, he might know if this is a duplicate.

Maybe #53308; we never got a clear comparison screenshot of identical fonts there though. Lets track it here since the description is clearer here, and then we can check back in with that issue after this is resolved.

Another option rather than dreding through the registry: use https://docs.microsoft.com/en-us/windows/win32/api/winddi/nf-winddi-drvenablepdev to get a GDIINFO, which has pixel structure in there as one of the values in the struct.

Unfortunately, getting the GDIINFO struct is not normally possible unless you're the kernel or the devicedriver exposes it as an extension. GetSystemCaps does not expose this specific piece of data, so it looks like the registry is the only way to go.

https://chromestatus.com/feature/6236420349100032

Microsoft is finally fixing Chrome's font issues on Windows 10 & 11
https://www.xda-developers.com/microsoft-fix-chrome-font-issues-windows-10-11/

I see this is a fix for Sika, will this benefit Flutter as well?

This is issue is not limited to Windows, is it?

At least my first steps with Flutter were on Linux and Web targets, and the poor font quality due to lack of subpixel hinting was immediately obvious in both as well. Should this be tracked in separate issues?

For my text-heavy use cases the lack of font hinting is a bit of a showstopper.

Flutter would benefit from this change on the web too.

@stuartmorgan-g

Just stumbled open this as well. Quality of font rendering is definitely worse than on mac:

All these sharp edges are pretty noticeable. Compare to macOS:

@stuartmorgan-g sorry if you are not the right person to ping. But just as a general question, curious if someone can provide a guideline in this ticket for the community that highlights:

Main problem / bottleneck why this is still stuck after so many years (I see an older discussion around raster cache, but unclear if that's actually the problem or if it's still is).
Potential solutions / approaches to address the issue.

Additionally, just guessing - any chance that move to Impeller would address the root cause (and which is why this hasn't been given any attention, since the fix would only apply to Skia, which is being phased out)?

"I’m struggling to see why the team labeled this a P2 issue. It’s a major blocker for developing production-grade PC applications. Given how much AI has boosted development efficiency lately, we should be leveraging AI to solve these problems rather than waiting on developers who aren't moving fast enough."

fix(app-server): bundle Noto Sans SC for even Chinese on desktop

feat(app-server): new-session UX — guidance, config inheritance, side…

We are building an enterprise IM application using Flutter for Windows desktop,
serving thousands of business users daily. Font rendering quality is a critical
blocker for us — it directly impacts message readability, which is the core
function of our product.

Our user environment:

~70% users on 1080p displays at 100% DPI scaling
~20-30% users on 2K/higher displays at 125-150% DPI
Primary content: Chinese/English mixed text, 14px body, dense message streams

Specific pain points:

CJK character strokes appear soft/blurry compared to native Windows apps
Non-integer DPI scaling (125%) causes visible sub-pixel misalignment
Mixed CJK+Latin text shows inconsistent stroke weight (ClearType fallback
renders differently across font families)

We have investigated this extensively. The root cause appears to be:

Flutter uses FreeType on Windows instead of DirectWrite/ClearType
SkScalerContext_DW hardcodes DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC
rather than calling GetRecommendedRenderingMode() per font/size
(Firefox fixed this in Bug 1321901 with measurable improvement)

We are willing to contribute engineering resources to help move this forward.
Is there an active workstream on this? We'd also appreciate clarity on whether
the planned Impeller-for-desktop rollout (2026 roadmap) is expected to address
text rendering quality specifically.

@dnfield

Update: Still reproducing on Flutter 3.44.0 (main channel) 鈥?comprehensive testing results

Confirmed this issue persists in the latest Flutter main channel (3.44.0). Sharing detailed findings from extensive testing in case it helps move this forward.

Environment

Flutter: 3.44.0 (main channel)
OS: Windows 10/11
DPI: 100% (1080p) and 125% (2K) scaling tested
Engine: Skia (Impeller is not available for Windows release builds 鈥?confirmed via source code tracing in flutter/shell/platform/windows/angle_surface_manager.cc)

What we tested

Font comparison 鈥?Built a side-by-side comparison page in a Flutter Windows app testing 6 fonts:

Microsoft YaHei UI (Windows system default UI font)
Microsoft YaHei (legacy system font)
Segoe UI (Segoe family)
HarmonyOS Sans SC (embedded, 3 weights)
Sarasa Gothic UI SC (embedded, 3 weights)
Noto Sans SC (embedded, variable font)

All fonts show visible blurriness compared to the same fonts rendered in native Win32 applications (Edge, Notepad, VS Code).

pixel_snap package 鈥?Integrated pixel_snap (replacing material.dart import with pixel_snap/material.dart). This improves pixel alignment for layout but does not address the fundamental anti-aliasing difference.

Font weight adjustment 鈥?Increasing body font weight from w400 to w500 partially mitigates the perceived blurriness by making strokes thicker, but this is a workaround, not a fix.

DPI scaling 鈥?Integer scaling (100%, 200%) is slightly better than fractional (125%, 150%), but the difference from native apps remains significant at all scales.

Root cause analysis

From our investigation:

Flutter uses grayscale anti-aliasing on Windows, not ClearType subpixel rendering. Native Windows apps use DirectWrite with ClearType by default.
Impeller is not available for Windows release builds. We traced the source code and confirmed Impeller can only be enabled in debug mode on Windows (--enable-impeller is silently ignored in release). The release path is hardcoded to Skia. So the hope that "Impeller will fix this" is not viable for production Windows apps in the near term.
The Skia surface properties (SkSurfaceProps) do not set kSubpixelAntialias 鈥?as @dnfield noted back in 2020, this requires wiring the pixel geometry through the embedder API.
As noted by other commenters, SkScalerContext_DW hardcodes DWRITE_RENDERING_MODE_NATURAL_SYMMETRIC rather than calling GetRecommendedRenderingMode() per font/size. Firefox fixed this in Bug 1321901 with measurable improvement.

Impact

For B2B/enterprise applications with text-heavy interfaces (chat, knowledge base, document viewers), this is a significant quality regression compared to native Windows applications. CJK character strokes appear soft/blurry, and mixed CJK+Latin text shows inconsistent stroke weight. Users have reported the text looking "out of focus", which affects readability for extended reading sessions.

Workarounds (not fixes)

Approach	Effect	Limitation
Font weight w400 鈫?w500	Partially masks blurriness	Changes typography design intent
`pixel_snap` package	Improves layout pixel alignment	Doesn't fix anti-aliasing
Integer DPI scaling	Slightly better	Not user-controllable in production
High-DPI displays (4K+)	Less noticeable	Doesn't help 1080p users (still majority)

Request

Is there any update on the timeline for this fix? Specifically:

Is the embedder API update to pass pixel geometry still planned?
Will Impeller for Windows desktop (when available) use DirectWrite with proper ClearType support?
Are there any community contribution opportunities here? We are willing to invest engineering resources.

This issue has been open since 2020 and affects production quality of Flutter Windows apps. Any guidance on priorities or a realistic timeline would be greatly appreciated.

We are also running into this issue in a production Flutter desktop application on Windows for Hyper Zones.

Text rendered is not very legible on our Windows app.

In our case, SF Pro renders well on macOS but poorly on Windows. We understand that SF Pro itself may not be ideal for Windows, but comparisons with other bundled fonts still show a broader difference between Flutter’s grayscale antialiasing and the ClearType/subpixel rendering users expect from native Windows applications.

This is not a stylistic preference, it's making an otherwise polished Flutter desktop applications feel visibly non-native and is affecting readability.

This image is full res from our windows test. It's not compressed:

Still reproducing on Flutter 3.47.0 (stable) on Windows 11 (26H2, build 26300) at 200% display scaling.

I maintain a desktop database client built with Flutter (Navicat-style UI, used mainly by CJK users). Both Latin and CJK text look visibly soft / out-of-focus compared to native Windows apps (Notepad, Edge, VS Code) — which points to the grayscale-vs-ClearType subpixel AA difference described here, not a font-fallback problem (English text is blurry too, so it is not just the Microsoft YaHei fallback missing).

Environment:

Flutter 3.47.0 • channel stable
Framework  revision 4cf2416426
Engine     revision 5f77625673
Dart 3.13.0
OS: Microsoft Windows [Version 10.0.26300.9711], locale zh-CN
Display scaling: 200%

For a text/table-heavy desktop tool this is the single biggest factor that makes a Flutter app feel "non-native" on Windows — the whole grid of cell values reads as blurry. +1 for raising the priority. Happy to test a branch that wires the subpixel pixel-geometry / kSubpixelAntialias through the embedder API, as discussed above.

Navigation Menu

Repository navigation

text rendering using subpixel / cleartype #63043

Use case

Proposal

17 remaining items

Update: Still reproducing on Flutter 3.44.0 (main channel) 鈥?comprehensive testing results

Environment

What we tested

Root cause analysis

Impact

Workarounds (not fixes)

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

text rendering using subpixel / cleartype #63043

Description

Use case

Proposal

Activity

dnfield commented on Oct 9, 2020

dnfield commented on Oct 9, 2020

dnfield commented on Oct 9, 2020

dnfield commented on Oct 13, 2020

dnfield commented on Oct 13, 2020

stuartmorgan-g commented on Oct 13, 2020

dnfield commented on Oct 13, 2020

dnfield commented on Oct 14, 2020

17 remaining items

jonathanffon commented on Dec 27, 2023

xkeyC commented on Mar 25, 2024

bluenote10 commented on May 28, 2024

kkseven commented on Nov 25, 2024

sgshy1995 commented on Jan 21, 2025

momadvisor commented on Feb 11, 2025

Wdestroier commented on Mar 3, 2025

pulyaevskiy commented on May 11, 2025

SuperAiPm commented on Apr 21, 2026

SuperAiPm commented on Jul 3, 2026

SuperAiPm commented on Jul 3, 2026

Update: Still reproducing on Flutter 3.44.0 (main channel) 鈥?comprehensive testing results

Environment

What we tested

Root cause analysis

Impact

Workarounds (not fixes)

Request

SaadArdati commented on Aug 5, 2026

SpringHgui commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions