Why Does Windows Display Scaling Make App Text Blurry? DPI Awareness, Bitmap Stretching, Per-Monitor Scaling, and Native Resolution Trade-offs Explained

｜ HK GPU Fix

重點摘要

When app text turns blurry under Windows display scaling, the monitor is often not at fault. Older programs that do not understand per-monitor dots per inch are rendered small and then stretched as a bitmap, so letter edges soften. This guide separates that scaling layer from non-native resolution, explains why only some apps blur, and gives tests for the cause.

Open display scaling on a high-resolution monitor, and a strange split appears on the same desktop: some programs show crisp text, while others look as though their text were seen through a thin haze. The first suspicion is often the monitor, or the cable. But when the blur is confined to particular programs while others stay sharp, the culprit is usually not in the monitor at all. It sits in the Windows display scaling layer: an older program that does not understand per-monitor dot density is drawn small and then stretched as a bitmap, and letter edges soften in the stretching. This guide explains three things: why scaling blurs text, why only some programs blur, and how seven ordered tests separate the scaling layer from every other layer. Two boundaries come first. Blur across the whole desktop points to the non-native resolution layer, covered in article 174. Scaling trouble in older full-screen games belongs to article 187. This guide covers only desktop programs and the system scaling layer.

What Scaling Is For: Logical Size Versus Physical Pixels

On a high-resolution display, pixels are so small that interface elements drawn one-to-one in physical pixels would be uncomfortably tiny. Display scaling exists to solve that: the system enlarges interface elements so text and buttons stay at a readable size. The key idea is "logical size". A program believes it is drawing on a smaller logical screen, and the system then maps that logical picture onto physical pixels. The larger the scaling, the smaller the logical picture relative to the physical screen, and the larger the magnification in the mapping.

That mapping decides whether text looks sharp or blurry. A program that understands scaling redraws its text and interface at the target size, recalculating letter strokes in physical pixels, so edges stay crisp. A program that does not understand scaling is drawn small, and the system stretches that small picture to the target size. Stretching creates no new detail; it only spreads the existing pixels apart, turning a sharp edge into a gradual transition, which the eye reads as blur. Scaling itself is not at fault; the mismatch is. The program's drawing size and the final display size disagree, and stretching bridges the gap at the cost of detail.

Three Levels of DPI Awareness Decide Which Programs Blur

Dot-density awareness — DPI awareness — describes whether a program understands the scaling environment it is in. In qualitative terms, there are three levels, and this guide gives no version numbers, because the level concept is what matters and version mappings change over time.

The first level is a program that does not understand scaling at all. It assumes a fixed dot density, draws its picture, and hands it to the system. The system, seeing that the program does not understand scaling, does the work instead: it stretches the finished bitmap to the target size. Programs at this level blur most easily at larger scaling, and the blur grows with the stretch: the more the picture is spread, the softer the letter edges become.

The second level is a program that understands only one system-wide scaling value. It draws correctly for the scaling value the system is currently using, so on a single display at a single scaling value it can look perfectly sharp. But move it to a second display with a different scaling value, and it does not redraw. The system keeps stretching the old-size picture, the whole program turns blurry on the new display, and only relaunching the program gives it a chance to draw sharply again. That pattern — blurry only after moving, sharp again after relaunch — is itself a diagnostic clue.

The third level is a program that understands each display's scaling value separately. It knows which display it is on and what scaling that display uses, and when it is moved, it redraws immediately, so the picture sharpens at once. Most modern programs sit at this level; most older programs sit at one of the first two. On the same desktop at the same scaling value, an aware program looks sharp and an unaware program looks blurry. That difference is expected behaviour, not favouritism by the display.

Why Bitmap Stretching Blurs, and Why Non-Integer Stretching Looks Worse

Bitmap stretching blur is easy to picture. A letter stroke drawn with a few pixels has a sharp edge: one pixel dark, the next light, a clean boundary. Stretch that picture, and the stroke must occupy more pixels, but the system has only the original few pixels of information and no knowledge of what should fill the gaps, so it spreads the original pixels and softens the edge into a gradient. The eye reads that gradient as blur, as a lack of solidity in the stroke.

Non-integer stretching looks worse because original pixels and target pixels do not line up evenly. With an integer stretch, each original pixel maps to a whole number of target pixels, and the spreading stays relatively even. With a non-integer stretch, some original pixels must spread further than others, so stroke thickness varies unevenly from row to row, and small text suffers most. That also explains why the same program can look blurrier at one scaling value than at another: the program has not changed, but the alignment of the stretch has.

One more limit must be stated: stretching never raises the resolution of text. Scaling enlarges the logical size; the detail ceiling is set by the size at which the program originally drew. Stretching a small bitmap as large as you like adds no detail beyond the original picture. No brightness, contrast, or cable change can restore detail that was never drawn.

Text and Icons Can Have Different Fates

Inside one program, text blur and icon blur can coexist for different reasons, and they must be recorded separately. Text can in principle be redrawn as vectors: an aware program recalculates letter strokes at the target size, keeping edges crisp. Icons and older interface elements, however, are often bitmaps themselves, and the program may simply have no higher-resolution version to substitute, so they stay blurry when enlarged. The combination "text sharp, icons blurry" therefore points to bitmap source material with no high-resolution version. The combination "text and icons blurry together" points to the whole bitmap being stretched. The two combinations lead in different directions, and a diagnosis that merely says "the whole program is blurry" throws that distinction away.

A program's own scaling setting is a separate layer from system scaling, and the two must not be mixed. Some programs offer their own zoom, which changes content size; system scaling changes the logical size of the whole program interface. System scaling blur is not cured by the program's own zoom, because the system stretch is still there underneath. Conversely, a program zoom set too large distorts content on its own, which is not a system scaling fault. In diagnosis, fix the program's own zoom first, then run the system scaling comparisons, never changing both at once.

Per-Monitor Scaling: The Full Explanation for "Blurry After Moving"

A two-display setup magnifies the per-monitor problem. Suppose the main display and the second display use different scaling values. Drag a program from one to the other, and an aware program redraws at once and sharpens immediately; a program that understands only one system-wide value does not redraw, the system keeps stretching the old-size picture, and the whole program turns blurry on the new display. Relaunch the program, and it draws at the new display's scaling value, so it sharpens again. That complete sequence explains why the same program, on the same day, can look sharp on the main display, blurry on the second display, and sharp again after relaunch: not a display that works intermittently, but awareness level combined with moving behaviour.

A single display can blur too, and that must be stated. A program that does not understand scaling blurs on a single high-scaling display just as well; it needs no second display to fail. A second display only makes the problem easier to expose, because moving the program presents the awareness difference immediately. Single-display users should not rule out the scaling layer merely because they own one display.

The Diagnostic Sequence, in Order

Run these steps in order. Each step changes exactly one thing, and the pattern of which changes matter is what identifies the cause. Changing several settings at once destroys the evidence.

Step 1: Establish the scope. Is the blur confined to particular programs, or is the whole desktop blurry? Particular programs point to the DPI awareness layer, and this guide continues. The whole desktop points to the resolution layer, and the investigation should turn to article 174 instead of circling inside scaling settings.

Step 2: Confirm native resolution. First confirm that the display is running at its native resolution. If it is not, the whole picture is being stretched, and text blur may have nothing to do with scaling at all. Only after native resolution is confirmed can later comparisons be attributed to the scaling layer.

Step 3: The no-scaling comparison. Temporarily return scaling to no magnification and look at the same program. Sharp again at no scaling confirms that the blur belongs to the scaling layer; still blurry at no scaling means it is not a scaling problem, and the investigation should return to other layers. This is the most important exclusion step in the guide; do not skip it.

Step 4: The move-between-displays comparison (two-display setups only). Drag the program from one display to another with a different scaling value, and watch whether the blur follows the move. Blurry only after moving, and sharp again after relaunch, points to a program that understands only one system-wide value; sharpening immediately on moving points to a per-display aware program. Single-display users may skip this step, but should note that they skipped it rather than treating it as done.

Step 5: The per-program DPI setting comparison. Using the program's compatibility DPI settings, try each option in turn, changing only one option at a time, and record which option sharpens the text and which distorts the layout. This is a trade-off test, not a standard answer: one option may sharpen text while distorting proportions, another may keep proportions while leaving text blurry, and the right choice depends on what the program is used for.

Step 6: The text-versus-icon comparison. Inside the same program, is the text blurry, or are the icons blurry, or both? Text sharp with icons blurry points to bitmap source material with no high-resolution version, which system settings cannot cure. Text and icons blurry together points to the whole bitmap being stretched, back to the awareness layer. The two conclusions differ, and must not be merged.

Step 7: The relaunch and re-sign-in comparison. After moving displays or changing scaling, relaunch the program, and if needed sign out and back in, then look again. Sharpening after relaunch points to an awareness-level matter, not a display fault. Still blurry after relaunch points to the source-material layer or another layer. That some programs need a relaunch before a scaling change takes effect is normal behaviour for their awareness level, not a fault, and mistaking it for "the setting did nothing" leads to endless circling through settings.

Boundary Cases Worth Knowing

Scaling does not change physical resolution. Enlarging the interface does not give text higher resolution; the detail ceiling is set by the size at which the program drew. This connects directly to the myth below about replacing the display.

A program update can change its awareness level. The same program may be per-display aware in a newer version and unaware in an older one, so behaviour can differ completely between versions. Diagnosis must rest on the current version's behaviour, not on a memory of how the program "always" behaved.

A screenshot may not reflect the blur as seen. The layer a screenshot captures is not necessarily the same as the composited picture the eye sees on the display, so diagnosis should rest on what the eye sees on the display itself, not on a single screenshot. When seeking a check, a spoken description — which program, which display, whether it was moved, what relaunch did — is more useful than a screenshot alone.

After a scaling change, some programs need a relaunch before the change takes effect. That is normal behaviour for their awareness level, not a fault. Reading it as failure leads to repeated setting changes and wasted time.

Five Myths, Dismantled

"Blurry text means the display is faulty or the cable is bad." Wrong. Blur confined to particular programs while others stay sharp is not a display-layer matter; the culprit sits in the scaling layer. The whole desktop blurring points to the resolution layer, and a fixed-position abnormality points to the panel layer. Scope comes first.

"Larger scaling makes text sharper." Wrong. Scaling enlarges logical size; bitmap stretching only softens letter edges further. Scaling exists to make the interface readable, not to raise the resolution of text.

"A higher-resolution display will fix it." Wrong. A higher-resolution display usually requires larger scaling, and for a program that does not understand scaling, the stretch grows larger and the blur can look worse. Confirm the layer with the seven steps before replacing anything, or the replacement may blur more.

"Every program should look equally sharp." Wrong. Awareness levels differ, so at the same desktop and the same scaling value, an aware program looks sharp and an unaware program looks blurry. That difference is expected behaviour, not a fault in the display.

"The program's own zoom can cure system scaling blur." Wrong. The two layers are separate. The program's own zoom changes content size, while the system bitmap stretch remains underneath. Zooming content larger does not remove the system layer's blur.

When It Is Worth Having the Machine Checked

Most cases end with a pattern from the table above and a setting choice that follows from it. A check is worth considering when the tests point in conflicting directions — for example, the blur persists in every test state, or it appears even at no scaling, or the display behaves oddly under other content. Those patterns point beyond settings to the display, its configuration, or another layer, and that is diagnosis work rather than settings work. Published inspection and repair pricing for this kind of work falls within the shop's three published tiers, from HK$400 to HK$2,800, depending on what the diagnosis finds; no figure outside that range should be quoted for this category. Our shop is at Room 1209, Dali Plaza, Shek Mun. The telephone number is 2186 8010 and WhatsApp is 6558 6806. There is no Mong Kok shop, and there is no on-site service; diagnosis is done at the shop. Before bringing anything in, write down the results of steps 1, 3, and 4 — the scope, the no-scaling comparison, and the move-between-displays result — because those three results narrow the investigation more than any description of the blur alone.

Frequently Asked Questions

Why do some programs show crisp text on the same display while others look blurry?

Because awareness levels differ. A per-display aware program redraws at the target size and stays crisp; a program that does not understand scaling must be stretched as a bitmap by the system, and its letter edges soften. At the same desktop and the same scaling value, the two behaviours are both expected.

Why does a program suddenly turn blurry when I drag it to the second display?

Because the two displays use different scaling values, and the program understands only one system-wide value. On moving, it does not redraw, the system keeps stretching the old-size picture, and the whole program blurs. Relaunching lets it draw at the new display's scaling value, so it may sharpen again. That pattern is itself the diagnostic clue.

If text sharpens again at no scaling, does that mean I can never use scaling?

No. The no-scaling comparison is a diagnostic step, used to confirm that the blur belongs to the scaling layer. Once confirmed, return to the per-program DPI setting comparison, trying each option and judging which sharpens text and which distorts layout, then choose by the program's use. No scaling is a diagnostic tool, not a permanent recommendation.

Text is sharp but icons are blurry. Have I set something wrong?

Not necessarily. Text can be redrawn as vectors, while icons may be bitmaps with no higher-resolution version available, so they stay blurry when enlarged. That combination points to the source-material layer, which system settings cannot cure, and endless setting changes will not help it.

Why do some programs need a relaunch before a scaling change takes effect?

Because of their awareness level. A program that understands only one system-wide value does not redraw automatically when scaling changes; it must be relaunched to draw at the new value. That is normal behaviour, not a fault, and it should not be read as the setting having failed.

The whole desktop is blurry, not just one program. Is that still the scaling layer?

Not necessarily. Blur across the whole desktop points first to the resolution layer: confirm that the display is running at its native resolution, since a non-native resolution stretches the whole picture, as covered in article 174. Only blur confined to particular programs belongs to this guide's scaling layer. Step 1 exists to separate those two.