VC++ Win32高DPI适配实战：从DPI获取到GDI绘图防失真

1. 项目概述：为什么高DPI适配成了Windows绘图开发绕不开的坎

“VC获取屏幕dpi，win32绘图适配高dpi模式，windows屏幕缩放图像拉伸失真问题”——这串标题里没有一个词是虚的，全是Windows桌面开发一线踩出来的坑。我从2012年开始做传统MFC/Win32图像处理软件，最早在1366×768的15.6寸笔记本上调试，那时连“DPI感知”这个词都很少见；直到2015年某高校实验室采购了一批Surface Pro 4，一打开我们做的图像标注工具，按钮小得像蚂蚁，文字糊成一片，右键菜单弹出来一半就切掉了——这才第一次被客户指着屏幕问：“你们这软件是不是没适配高清屏？”

真正让问题爆发的是Windows 10 1607版本强制启用“每显示器DPI缩放”（Per-Monitor DPI Awareness），系统不再统一按主屏缩放比例拉伸整个进程，而是允许每个显示器独立设置100%、125%、150%甚至200%缩放。这时候如果你的VC程序还是用GDI画一个100×100像素的矩形，它在150%缩放的4K屏上实际物理尺寸会比100%屏上大整整1.5倍，但字体、控件、位图资源却不会自动等比放大——结果就是UI元素错位、文字锯齿、图像拉伸变形、坐标计算全乱套。更麻烦的是，很多老项目依赖GetDeviceCaps(LOGPIXELSX)硬编码获取96dpi，一旦系统缩放开启，这个值就变成144或192，而你的绘图逻辑还按96算，所有坐标偏移、缩放因子、字体高度全崩了。

这个问题的本质不是“画不画得清”，而是“画在哪、画多大、怎么算”。它横跨三个层面：系统层（Windows如何报告DPI）、API层（GDI/GDI+/Direct2D对DPI的响应机制）、应用层（你代码里所有像素级硬编码是否做了缩放解耦）。标题里提到的三个关键词，其实是同一问题的三把钥匙：

• “VC获取屏幕dpi”解决的是感知能力——你得先知道当前窗口在哪个显示器、缩放比是多少；
• “win32绘图适配高dpi模式”解决的是响应能力——拿到dpi后，如何让GDI绘图、字体渲染、位图缩放跟着动态调整；
• “windows屏幕缩放图像拉伸失真问题”则是验证标尺——最终用户看到的图像有没有变形、文字是否清晰、鼠标点击区域是否准确，全靠它来检验。

适合谁看？如果你正在维护一个用VC++写的MFC/ATL/纯Win32图像处理、CAD辅助、工业检测或医疗影像软件，且用户开始抱怨“在新电脑上界面太小/模糊/点不准”，那这篇就是为你写的。不需要你懂DirectX或现代UI框架，我们只聊原生Win32下最扎实、最可控、也最容易被忽略的底层适配方案。实测下来，一套完整的高DPI适配改造，能让一个10年老项目在Windows 11 22H2的200%缩放Surface Laptop Studio上，字体锐利如初、图像无拉伸、坐标零偏差——关键不在重写，而在理清逻辑。

2. 核心设计思路：为什么必须分三步走，而不是直接调SetProcessDpiAwareness？

很多人看到“高DPI适配”第一反应是查MSDN，找到SetProcessDpiAwareness这个API，心想“设成PER_MONITOR_DPI_AWARE不就完了？”——我试过，也劝退过至少5个团队。2017年帮某医疗器械公司改一个内窥镜图像实时标注系统时，开发组长信心满满地加了两行代码：

#include <shellscalingapi.h> SetProcessDpiAwareness(PER_MONITOR_DPI_AWARE);

编译运行，结果更糟：主界面正常了，但弹出的子窗口（比如ROI选择对话框）直接消失在屏幕外，鼠标拖动窗体时坐标跳变，连关闭按钮都点不中。问题出在哪？因为Windows的DPI感知模型不是“开关式”的，而是分阶段演进的三层架构，跳过中间层直接上最高阶，等于让一个没学过加减法的人直接解微分方程。

2.1 Windows DPI感知模型的演进逻辑

微软从Vista到Win11，DPI适配走了三条技术路径，每条对应不同的兼容性与控制粒度：

关键点在于：PER_MONITOR_DPI_AWARE不是“设了就稳”，而是“设了就要管”。它把DPI控制权完全交给你，系统不再帮你做任何拉伸或缩放，所有坐标转换、字体创建、位图绘制都得自己算。而绝大多数VC老项目，代码里散落着成百上千处“x=100, y=50, width=200”这样的硬编码像素值，还有大量基于GetClientRect获取的像素尺寸做布局计算——这些全得重构。

所以我的方案是分三步走，不是为了炫技，而是为了可控落地：

1. 先感知：用最轻量的方式获取当前窗口真实DPI，不改主线程逻辑，只做诊断；
2. 再隔离：把所有像素级计算抽离成“逻辑坐标→物理像素”的转换层，用缩放因子解耦；
3. 最后适配：在关键消息（WM_CREATE/WM_DPICHANGED/WM_SIZE）中注入重绘逻辑，确保窗口生命周期内DPI变更可响应。

这就像修一栋老房子，不能一上来就拆承重墙。先装传感器测沉降（感知），再给梁柱加钢架分散应力（隔离），最后才换地基（适配）。每一步都有明确输出：第一步能打印出当前DPI值验证环境；第二步让所有绘图函数接受“逻辑尺寸”参数；第三步让窗口在125%和200%缩放间切换时，图像不变形、文字不糊、按钮不跑位。后面所有实操，都围绕这三步展开。

2.2 为什么GDI绘图必须放弃“像素即真理”的思维

Win32开发有个根深蒂固的惯性：认为“1像素=1物理点”。这种思维在96dpi时代天衣无缝，但在150%缩放下，1个逻辑像素（logical pixel）可能对应2.25个物理像素（physical pixel）——因为Windows采用亚像素渲染（ClearType），实际是用RGB子像素做灰度混合。如果你用GDI画一条1像素宽的线：

MoveToEx(hdc, 100, 100, NULL); LineTo(hdc, 200, 100); // 期望画100px长的水平线

在150%缩放下，这段代码实际执行的是：

• MoveToEx把逻辑坐标(100,100)乘以缩放因子1.5 → (150,150)物理坐标；
• LineTo把(200,100)转成(300,150)，画出150px长的线；
• 但你的业务逻辑可能还按100px算长度，导致后续所有基于此线的几何计算（比如垂直距离、包围盒）全错。

更隐蔽的问题在文本渲染。GDI的TextOut默认按设备上下文的映射模式（MM_TEXT）工作，即1逻辑单位=1像素。当你用CreateFont创建12号字体时：

LOGFONT lf = {0}; lf.lfHeight = -MulDiv(12, GetDeviceCaps(hdc, LOGPIXELSY), 72); // 关键！这里用了LOGPIXELSY

如果GetDeviceCaps(hdc, LOGPIXELSY)返回144（150%缩放），那么lfHeight算出来是-24，字体实际大小是24像素；但如果代码里漏了这行MulDiv，直接写lfHeight = -12，那字体永远是12像素，在高缩放屏上小得无法阅读。

所以核心转变是：把“像素”从数据类型升级为带单位的量纲。就像物理公式里不能把“10米”和“10秒”直接相加，你的代码里也不能把“100逻辑像素”和“100物理像素”混用。我在所有项目里强制推行一个规则：

• 所有接口参数、成员变量、配置文件里的尺寸，统一用“逻辑像素”（logical pixel）；
• 所有GDI调用前，用ScaleLogicalToPhysical()函数转成物理像素；
• 所有鼠标坐标、窗口尺寸回调（如GetWindowRect），用ScalePhysicalToLogical()转回逻辑像素。

这个转换函数不是简单乘除，它要处理DPI跃变时的整数舍入误差。比如100逻辑像素×1.5=150物理像素没问题，但101×1.5=151.5，GDI只能取整到151或152——取整方向错了，连续绘图就会出现1像素间隙或重叠。我在ScaleLogicalToPhysical里加了银行家舍入（Banker's Rounding），让偶数.5向下取，奇数.5向上取，保证多段线连接时端点严丝合缝。这些细节，才是让图像“不拉伸失真”的真正底座。

3. 核心实现细节：从获取DPI到GDI绘图的全链路改造

现在进入实操环节。我会带你从零开始，把一个典型的VC++ MFC对话框程序（比如一个图像查看器）改造成高DPI安全的版本。所有代码基于Visual Studio 2019 + Windows SDK 10.0.19041，不依赖第三方库，纯Win32 API。重点不是贴代码，而是讲清楚每一行背后的“为什么”。

3.1 第一步：安全获取当前窗口DPI——不用SetProcessDpiAwareness也能准确定位

很多教程一上来就教你怎么改manifest文件或调SetProcessDpiAwareness，但这是危险的。在没摸清当前环境DPI行为前，盲目开启高感知，可能让程序直接无法启动（比如某些驱动hook会拦截DPI API）。我的做法是：先用最保守的方式读取DPI，作为诊断入口。

Windows提供两个层级的DPI查询API，必须分清使用场景：

• GetDpiForWindow(HWND)：返回指定窗口所在显示器的有效DPI（effective DPI），即系统当前应用的缩放比例。这是最准的，但要求Windows 10 1607+；
• GetDpiForMonitor(HMONITOR, MONITOR_DPI_TYPE, ...)：返回指定显示器的原始DPI（raw DPI），即显示器物理PPI值，与系统缩放无关。比如4K屏物理PPI是216，但系统设125%缩放时，有效DPI是216×1.25=270。

对于老项目兼容，我推荐双保险方案：先尝试GetDpiForWindow，失败则回退到GetDeviceCaps。关键代码如下（封装成静态函数，供全局调用）：

// DPIHelper.h #pragma once #include <windows.h> #include <shellscalingapi.h> class CDPIHelper { public: // 获取窗口当前有效DPI（推荐） static UINT GetWindowDPI(HWND hWnd) { if (hWnd == NULL) return 96; // Windows 10 1607+ 支持 static auto pGetDpiForWindow = (UINT(WINAPI*)(HWND))GetProcAddress(GetModuleHandle(L"User32.dll"), "GetDpiForWindow"); if (pGetDpiForWindow) { return pGetDpiForWindow(hWnd); } // 回退：用GetDC + GetDeviceCaps（仅主显示器） HDC hdc = GetDC(hWnd); if (hdc) { UINT dpi = GetDeviceCaps(hdc, LOGPIXELSX); ReleaseDC(hWnd, hdc); return dpi; } return 96; } // 计算缩放因子（逻辑像素→物理像素） static float GetScaleFactor(HWND hWnd) { UINT dpi = GetWindowDPI(hWnd); return static_cast<float>(dpi) / 96.0f; // 以96dpi为基准 } };

提示：GetDpiForWindow在Windows 10 1607前不可用，必须用GetProcAddress动态加载，否则老系统直接报错。我见过太多项目因为硬链接这个API，导致在Windows 7上安装失败。

这个函数的价值在于：它让你在不改变进程感知级别的前提下，就能拿到当前窗口的真实DPI。比如在MFC对话框的OnInitDialog中：

BOOL CImageViewDlg::OnInitDialog() { CDialogEx::OnInitDialog(); UINT dpi = CDPIHelper::GetWindowDPI(m_hWnd); float scale = CDPIHelper::GetScaleFactor(m_hWnd); TRACE(_T("DPI: %u, Scale: %.2f\n"), dpi, scale); // 输出：DPI: 144, Scale: 1.5 // 后续所有尺寸计算，都用scale做转换 m_nImageWidth = static_cast<int>(m_nOriginalWidth * scale); m_nImageHeight = static_cast<int>(m_nOriginalHeight * scale); return TRUE; }

注意这里m_nImageWidth是物理像素尺寸，用于GDI绘图；而m_nOriginalWidth是逻辑尺寸，存原始图像宽高，业务逻辑全基于它。这种分离，是避免“拉伸失真”的第一道防线——图像缩放由你控制，而不是让系统用双线性插值暴力拉伸。

3.2 第二步：构建DPI无关的绘图层——GDI坐标转换的黄金法则

有了DPI感知能力，下一步是让所有GDI绘图脱离“像素直觉”。核心原则：GDI只负责物理像素绘制，所有业务逻辑在逻辑坐标系中运算。这意味着你要重写所有涉及坐标的函数。

3.2.1 逻辑坐标到物理坐标的转换矩阵

GDI本身不提供坐标系抽象，所以得自己建。我定义一个CLogicalRect结构体，封装逻辑矩形，并提供转物理坐标的接口：

struct CLogicalRect { int left, top, right, bottom; CLogicalRect(int l=0, int t=0, int r=0, int b=0) : left(l), top(t), right(r), bottom(b) {} // 转为物理RECT（用于FillRect/FrameRect等） RECT ToPhysicalRect(HWND hWnd) const { float scale = CDPIHelper::GetScaleFactor(hWnd); RECT rc = {0}; rc.left = static_cast<LONG>(roundf(left * scale)); rc.top = static_cast<LONG>(roundf(top * scale)); rc.right = static_cast<LONG>(roundf(right * scale)); rc.bottom = static_cast<LONG>(roundf(bottom * scale)); return rc; } // 转为物理POINT（用于MoveToEx/LineTo） POINT ToPhysicalPoint(HWND hWnd, const POINT& pt) const { float scale = CDPIHelper::GetScaleFactor(hWnd); POINT ptPhys = {0}; ptPhys.x = static_cast<LONG>(roundf(pt.x * scale)); ptPhys.y = static_cast<LONG>(roundf(pt.y * scale)); return ptPhys; } };

关键点在roundf——用四舍五入而非截断。比如逻辑坐标(100.3, 200.7)在150%缩放下，物理坐标应为(150, 301)，而不是(150, 300)。少这1像素，在图像边缘可能造成1像素黑边或白边，尤其在抗锯齿渲染时特别明显。

3.2.2 GDI绘图函数的封装层

直接调用Rectangle(hdc, x1,y1,x2,y2)风险极高，因为x1/y1等都是物理像素。我封装一层安全绘图函数：

// SafeGDI.h class CSafeGDI { public: // 安全画矩形（输入逻辑坐标） static BOOL DrawRect(HDC hdc, HWND hWnd, const CLogicalRect& lr, COLORREF color) { RECT rcPhys = lr.ToPhysicalRect(hWnd); HBRUSH hBrush = CreateSolidBrush(color); BOOL ret = FillRect(hdc, &rcPhys, hBrush); DeleteObject(hBrush); return ret; } // 安全画线（输入逻辑坐标） static BOOL DrawLine(HDC hdc, HWND hWnd, int x1, int y1, int x2, int y2, COLORREF color) { float scale = CDPIHelper::GetScaleFactor(hWnd); POINT pt1 = {static_cast<LONG>(roundf(x1 * scale)), static_cast<LONG>(roundf(y1 * scale))}; POINT pt2 = {static_cast<LONG>(roundf(x2 * scale)), static_cast<LONG>(roundf(y2 * scale))}; HPEN hPen = CreatePen(PS_SOLID, 1, color); // 注意：笔宽1是物理像素，固定 HPEN hOldPen = (HPEN)SelectObject(hdc, hPen); MoveToEx(hdc, pt1.x, pt1.y, NULL); LineTo(hdc, pt2.x, pt2.y); SelectObject(hdc, hOldPen); DeleteObject(hPen); return TRUE; } };

注意：CreatePen的宽度参数是物理像素，所以设为1表示“始终画1物理像素宽的线”，这符合设计意图——无论缩放多少，UI边框粗细一致。如果你希望边框也随缩放变粗（比如设计稿要求“2逻辑像素宽”），那就得改成static_cast<int>(2 * scale)。

3.2.3 图像缩放的防失真关键：用StretchBlt还是SetStretchBltMode？

图像拉伸失真是高DPI最头疼的问题。用户抱怨“图片模糊”，90%是因为用了默认的StretchBlt双线性插值。Windows提供了更高级的缩放模式：

// 在OnPaint中 void CImageViewDlg::OnPaint() { CPaintDC dc(this); CDC memDC; memDC.CreateCompatibleDC(&dc); // 设置高质量缩放模式（关键！） SetStretchBltMode(memDC.m_hDC, HALFTONE); // 比COLORONCOLOR更平滑 SetBrushOrgEx(memDC.m_hDC, 0, 0, NULL); // 重置画刷原点，避免HALFTONE偏移 // 计算逻辑显示区域 CRect rcClient; GetClientRect(&rcClient); CLogicalRect lrDisplay(rcClient.left, rcClient.top, rcClient.right, rcClient.bottom); // 转为物理尺寸 RECT rcPhys = lrDisplay.ToPhysicalRect(m_hWnd); // 安全绘制图像（假设m_hBitmap是原始位图） StretchBlt(dc.m_hDC, rcPhys.left, rcPhys.top, rcPhys.right - rcPhys.left, rcPhys.bottom - rcPhys.top, memDC.m_hDC, 0, 0, m_nOriginalWidth, m_nOriginalHeight, SRCCOPY); }

HALFTONE模式比默认COLORONCOLOR好得多，它用加权平均采样，减少摩尔纹。但要注意两点：

1. 必须调用SetBrushOrgEx重置画刷原点，否则HALFTONE在非整数缩放比下会偏移1像素；
2. StretchBlt的源尺寸（m_nOriginalWidth）必须是原始图像的逻辑宽高，不能是物理尺寸——否则会二次缩放。

我实测过：一张2000×1500的医学CT图像，在200%缩放下，用COLORONCOLOR拉伸后边缘发虚，用HALFTONE+正确原点设置后，纹理清晰度几乎无损。这不是玄学，是Windows图形子系统对亚像素采样的优化。

3.3 第三步：响应DPI变更——WM_DPICHANGED消息的完整处理链

这才是Per-Monitor DPI Aware的核心。当用户把窗口从100%缩放的笔记本拖到150%缩放的4K显示器时，系统会发送WM_DPICHANGED消息，通知你“环境变了，快重绘”。但很多开发者只处理了重绘，忘了窗口尺寸重置。

WM_DPICHANGED的wParam是新DPI值，lParam是一个RECT*，指向建议的新窗口尺寸（以逻辑像素为单位）。很多人直接忽略这个RECT，自己用GetClientRect算尺寸，结果窗口在高缩放屏上被裁剪。正确流程是：

1. 保存旧DPI和旧尺寸；
2. 调用SetWindowPos按lParam的RECT调整窗口大小；
3. 强制重绘整个客户区；
4. 更新所有缓存的物理尺寸（如位图缓冲区）。

MFC中的典型实现：

// 在对话框类中 LRESULT CImageViewDlg::OnDpiChanged(WPARAM wParam, LPARAM lParam) { // lParam 是 LPRECT，指向建议的新窗口尺寸（逻辑像素） LPRECT pRect = reinterpret_cast<LPRECT>(lParam); if (pRect == nullptr) return 0; // 步骤1：保存旧DPI，用于对比 UINT oldDPI = m_uCurrentDPI; m_uCurrentDPI = static_cast<UINT>(wParam); // 步骤2：用建议尺寸调整窗口（关键！） // 注意：pRect是逻辑像素，SetWindowPos需要物理像素 float scaleNew = static_cast<float>(m_uCurrentDPI) / 96.0f; RECT rcNewPhys = {0}; rcNewPhys.left = static_cast<LONG>(roundf(pRect->left * scaleNew)); rcNewPhys.top = static_cast<LONG>(roundf(pRect->top * scaleNew)); rcNewPhys.right = static_cast<LONG>(roundf(pRect->right * scaleNew)); rcNewPhys.bottom = static_cast<LONG>(roundf(pRect->bottom * scaleNew)); SetWindowPos(NULL, rcNewPhys.left, rcNewPhys.top, rcNewPhys.right - rcNewPhys.left, rcNewPhys.bottom - rcNewPhys.top, SWP_NOZORDER | SWP_NOACTIVATE); // 步骤3：强制重绘 InvalidateRect(NULL, TRUE); // 步骤4：重建位图缓冲区（如果用了内存DC） if (m_hMemBitmap) { DeleteObject(m_hMemBitmap); m_hMemBitmap = NULL; } return 0; } // 消息映射 BEGIN_MESSAGE_MAP(CImageViewDlg, CDialogEx) ON_WM_PAINT() ON_MESSAGE(WM_DPICHANGED, &CImageViewDlg::OnDpiChanged) END_MESSAGE_MAP()

注意：SWP_NOZORDER | SWP_NOACTIVATE确保只改尺寸位置，不改变窗口层级或焦点，避免用户操作中断。

这个处理链必须完整。我曾遇到一个bug：某工业相机采集软件在DPI变更后，图像显示区域缩小了一半。排查发现，开发人员只调了InvalidateRect，但没调SetWindowPos，导致GetClientRect返回的仍是旧尺寸，而StretchBlt按新DPI缩放，结果图像被压缩进一半区域。补上SetWindowPos后，问题消失。

4. 实操全流程：从新建项目到真机验证的7个关键步骤

现在把前面所有知识点串起来，走一遍完整实操。我以Visual Studio 2019新建一个MFC对话框程序为例，目标是让一个简单的图像查看器在125%/150%/200%缩放下，图像不拉伸、文字不糊、按钮不跑位。全程不依赖任何第三方库，纯Win32。

4.1 步骤1：创建基础项目并添加DPI辅助类

1. VS中新建MFC Application，类型选“Dialog based”；
2. 在解决方案中新建头文件DPIHelper.h和DPIHelper.cpp，粘贴3.1节的CDPIHelper代码；
3. 在stdafx.h中添加：

#define _WIN32_WINNT 0x0A00 // Windows 10 #include <shellscalingapi.h> #pragma comment(lib, "Shcore.lib") // 链接Shcore.lib

提示：Shcore.lib是SetProcessDpiAwareness等API必需的，不加会链接错误。_WIN32_WINNT宏确保SDK用最新定义。

4.2 步骤2：修改Manifest文件声明感知级别

右键项目→“属性”→“配置属性”→“清单工具”→“输入和输出”→“附加清单文件”，填入：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware> <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness> </windowsSettings> </application> </assembly>

关键点：

• <dpiAware>true/pm</dpiAware>兼容旧系统（Windows 8.1及以下）；
• <dpiAwareness>PerMonitorV2, PerMonitor</dpiAwareness>优先用V2（支持任务栏图标缩放），降级到V1；
• PerMonitorV2要求Windows 10 1703+，但manifest里写两个确保兼容。

4.3 步骤3：在App类中初始化进程感知

在CxxxApp::InitInstance()开头添加：

// 启用每显示器DPI感知（必须在CreateDialog前） if (IsWindows10OrGreater()) { SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2); } else { SetProcessDpiAwareness(PER_MONITOR_DPI_AWARE); }

IsWindows10OrGreater()是VersionHelpers.h里的函数，需包含头文件。这行代码确保进程启动时就进入高感知模式，否则WM_DPICHANGED不会触发。

4.4 步骤4：改造对话框类，注入DPI感知逻辑

在对话框头文件中添加成员变量：

class CImageViewDlg : public CDialogEx { // ... 其他代码 private: UINT m_uCurrentDPI; // 当前DPI缓存 CSize m_szOriginalImage; // 原始图像逻辑尺寸 CBitmap m_bmpImage; // 原始位图（逻辑尺寸） };

在OnInitDialog中初始化：

BOOL CImageViewDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 初始化DPI m_uCurrentDPI = CDPIHelper::GetWindowDPI(m_hWnd); // 加载原始图像（假设资源ID为IDB_IMAGE） m_bmpImage.LoadBitmap(IDB_IMAGE); BITMAP bmpInfo; m_bmpImage.GetBitmap(&bmpInfo); m_szOriginalImage = CSize(bmpInfo.bmWidth, bmpInfo.bmHeight); // 计算初始显示尺寸（逻辑像素） CRect rcClient; GetClientRect(&rcClient); m_rcDisplay = CRect(0, 0, rcClient.Width(), rcClient.Height()); return TRUE; }

4.5 步骤5：重写OnPaint，使用安全绘图层

void CImageViewDlg::OnPaint() { CPaintDC dc(this); CDC memDC; memDC.CreateCompatibleDC(&dc); // 创建兼容位图（物理尺寸） CRect rcClient; GetClientRect(&rcClient); CLogicalRect lrClient(rcClient.left, rcClient.top, rcClient.right, rcClient.bottom); RECT rcPhys = lrClient.ToPhysicalRect(m_hWnd); CBitmap bmpMem; bmpMem.CreateCompatibleBitmap(&dc, rcPhys.right - rcPhys.left, rcPhys.bottom - rcPhys.top); CBitmap* pOldBmp = memDC.SelectObject(&bmpMem); // 清空背景 CBrush brush(RGB(240,240,240)); memDC.FillRect(&rcPhys, &brush); // 绘制图像（用HALFTONE防失真） SetStretchBltMode(memDC.m_hDC, HALFTONE); SetBrushOrgEx(memDC.m_hDC, 0, 0, NULL); StretchBlt(memDC.m_hDC, 0, 0, rcPhys.right - rcPhys.left, rcPhys.bottom - rcPhys.top, CDC::FromHandle(m_bmpImage.GetSafeHandle())->m_hDC, 0, 0, m_szOriginalImage.cx, m_szOriginalImage.cy, SRCCOPY); // 绘制边框（逻辑坐标转物理） CLogicalRect lrBorder(5, 5, rcClient.Width()-5, rcClient.Height()-5); CSafeGDI::DrawRect(memDC.m_hDC, m_hWnd, lrBorder, RGB(0,120,215)); // 拷贝到屏幕 dc.BitBlt(0, 0, rcPhys.right - rcPhys.left, rcPhys.bottom - rcPhys.top, &memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOldBmp); }

这里StretchBlt的源尺寸用m_szOriginalImage（逻辑像素），目标尺寸用rcPhys（物理像素），缩放由GDI完成，你只控制输入输出，杜绝失真。

4.6 步骤6：添加WM_DPICHANGED处理，确保动态响应

按3.3节代码实现OnDpiChanged，并确保消息映射正确。测试时，把窗口拖到不同缩放的显示器，观察是否自动调整大小和重绘。

4.7 步骤7：真机验证与常见问题排查

部署到真实高分屏测试：

• Windows 10 20H2 150%缩放：检查图像边缘是否锐利，文字是否无锯齿；
• Windows 11 22H2 200%缩放：拖动窗口跨显示器，确认无闪烁、无错位；
• 混合缩放（主屏100%，副屏150%）：验证GetDpiForWindow返回值是否随窗口移动实时变化。

我整理了一份真机验证速查表，覆盖90%的现场问题：