WPF开发中，DPI 相关的资料记录

子不语

已于 2024-11-19 10:57:37 修改

阅读量1.1k

点赞数 9

分类专栏： WPF 文章标签： wpf DPI 分辨率显示清晰

于 2024-11-19 10:18:43 首次发布

本文链接：https://blog.youkuaiyun.com/qq_43307934/article/details/143873007

版权

WPF 专栏收录该内容

109 篇文章

订阅专栏

1、支持 Windows 10 最新 PerMonitorV2 特性的 WPF 多屏高 DPI 应用开发

版权声明：本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。欢迎转载、使用、重新发布，但务必保留文章署名吕毅（包含链接：http://blog.youkuaiyun.com/wpwalter/），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我联系（walter.lv@qq.com）。 https://blog.youkuaiyun.com/WPwalter/article/details/83476895

Windows 10 自 1703 开始引入第二代的多屏 DPI 机制（PerMonitor V2），而 WPF 框架可以支持此第二代的多屏 DPI 机制。

本文将介绍 WPF 框架利用第二代多屏 DPI 机制进行高 DPI 适配的方法。同时，也介绍低版本的 WPF 或者低版本的操作系统下如何做兼容。

本文内容

- - 添加应用程序清单文件
    - 如果你没有 app.config，如何添加？
    - 如果你没有 app.manifest，如何添加？
  - 了解 WPF 清单文件中的 DPI 感知设置
    - DpiAware
    - DpiAwareness
  - 使 WPF 程序支持 Per-Monitor V2 级 DPI 感知
  - WPF 程序在特殊清单设置下的效果
  - 低版本 .NET Framework 和低版本 Windows 下的 WPF DPI 缩放
    - 参考资料

添加应用程序清单文件

在你现有 WPF 项目的主项目中需要添加两个文件以支持第二代的多屏 DPI 机制。

app.manifest (决定性文件)
app.config (修复 Bug, .NET Framework 4.6.2 及以上可忽略)

在这里插入图片描述

▲ 项目中新增的两个文件

默认情况下，app.config 在你创建 WPF 项目的时候就会存在，而 app.manifest 则不是。如果你的项目中已经存在这两个文件，就不需要添加了。

如果你没有 app.config，如何添加？

打开项目属性，然后在属性中选择 .NET Framework 的版本，无论你选择哪个，app.config 都会自动为你添加。

选择 .NET Framework 版本以便添加 app.config 文件

当然，正统的方法是跟下面的 app.manifest 的添加方法相同，你会在下面看到 Visual Studio 新建项中 app.manifest 和 app.config 文件是挨在一起的。

如果你没有 app.manifest，如何添加？

▲ 新建文件的时候选择应用程序清单文件（应用程序配置文件就在旁边）

了解 WPF 清单文件中的 DPI 感知设置

DpiAware

在你打开了 app.manifest 文件后，找到以下代码，然后取消注释：

<!-- Indicates that the application is DPI-aware and will not be automatically scaled by Windows at higher
    DPIs. Windows Presentation Foundation (WPF) applications are automatically DPI-aware and do not need 
    to opt in. Windows Forms applications targeting .NET Framework 4.6 that opt into this setting, should 
    also set the 'EnableWindowsFormsHighDpiAutoResizing' setting to 'true' in their app.config. -->
<!--
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
-->

上面这一段代码是普通的 DPI 感知的清单设置，开启后获得系统 DPI 感知级别（System DPI Awareness）。

如果要开启 Per-Monitor DPI 感知，将上面的 true 改成 true/pm（pm 表示 per-monitor）。

不过这只是兼容性的设计而已，感谢老版本的系统使用字符串包含的方式，于是可以老版本的系统可以兼容新的 DPI 感知值：

什么都不填
- 如果你额外也没做什么 DPI 相关的操作，那么就是 Unaware。
- 如果你在程序启动的时候调用了 SetProcessDpiAwareness 或 SetProcessDPIAware 函数，那么就会按照调用此函数的效果来感知 DPI。
包含 true 字符串
- 当前进程设置为系统级 DPI 感知（System DPI Awareness）。
包含 false 字符串
- 在 Windows Vista / 7 / 8 中，与什么都不填的效果是一样的。
- 在 Windows 8.1 / 10 中，当前进程设置为不感知 DPI（Unaware），就算你调用了 SetProcessDpiAwareness 和 SetProcessDPIAware 也是没有用的。
包含 true/pm 字符串
- 在 Windows Vista / 7 / 8 中，当前进程设置为系统级 DPI 感知（System DPI Awareness）。
- 在 Windows 8.1 / 10 中，当前进程设置为屏幕级 DPI 感知（Per-Monitor DPI Awareness）。
包含 per monitor 字符串
- 在 Windows Vista / 7 / 8 中，与什么都不填的效果是一样的。
- 在 Windows 8.1 / 10 中，当前进程设置为屏幕级 DPI 感知（Per-Monitor DPI Awareness）。
其他任何字符串
- 在 Windows Vista / 7 / 8 中，与什么都不填的效果是一样的。
- 在 Windows 8.1 / 10 中，当前进程设置为不感知 DPI（Unaware），就算你调用了 SetProcessDpiAwareness 和 SetProcessDPIAware 也是没有用的。

说明一下，SetProcessDpiAwareness 是新 API，要求的最低系统版本是 Windows 8.1，调用这个才能指定为 Per-Monitor 的 DPI 感知。而 SetProcessDPIAware 是 Vista 开始引入的老 API，没有参数可以传。

DpiAwareness

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
    <dpiAwareness>PerMonitorV2, unaware</dpiAwareness>
  </asmv3:windowsSettings>
</asmv3:application>

注意：只有 Windows 10 (1607) 及以上版本才会识别此节点的 DPI 设置。如果你设置了 dpiAwareness 节点，那么 dpiAware 就会被忽略。

建议你可以两个节点都指定，这样既可以使用到 Windows 10 1607 的新特性，又可以兼容老版本的 Windows 操作系统。

dpiAwareness 节点支持设置一个或多个 DPI 感知级别，用逗号分隔。如果你指定了多个，那么操作系统会从第一个开始识别，如果能识别就使用，否则会找第二个。用这种方式，未来的应用可以指定当前系统不支持的 DPI 感知级别。

鉴于此，在目前 Windows 7 还大行其道的今天，为了兼容，dpiAwareness 和 dpiAware 都设置是比较靠谱的。

dpiAwareness 节点目前支持的值有：

什么都不设置
- 按 dpiAware 节点的结果来
整个逗号分隔的序列都没有能识别的 DPI 感知级别
- 如果你额外也没做什么 DPI 相关的操作，那么就是 Unaware。
- 如果你在程序启动的时候调用了 SetProcessDpiAwareness 或 SetProcessDPIAware 函数，那么就会按照调用此函数的效果来感知 DPI。
第一个能识别的感知级别是 system
- 当前进程设置为系统级 DPI 感知（System DPI Awareness）。
第一个能识别的感知级别是 permonitor
- 当前进程设置为屏幕级 DPI 感知（Per-Monitor DPI Awareness）。
第一个能识别的感知级别是 permonitorv2
- 当前进程设置为第二代屏幕级 DPI 感知（Per-Monitor V2 DPI Awareness）。
- 仅在 Windows 10 (1703) 及以上版本才可被识别
第一个能识别的感知级别是 unaware
- 当前进程设置为不感知 DPI（Unaware），就算你调用了 SetProcessDpiAwareness 和 SetProcessDPIAware 也是没有用的。

使 WPF 程序支持 Per-Monitor V2 级 DPI 感知

前面我们分析 App.Manifest 文件中 DPI 的设置后，几乎得到一个信息，dpiAware 和 dpiAwareness 都是要设置的，除非以后绝大多数用户的系统版本都到达 Windows 10 (1607) 及以上。

以下是推荐的 DPI 感知级别设置：

<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <!-- The combination of below two tags have the following effect : 
         1. Per-Monitor for >= Windows 10 Anniversary Update
         2. System < Windows 10 Anniversary Update -->
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
  </windowsSettings>
</application>

需要注意：

你的 .NET Framework 版本必须在 4.6.2 以上才建议这么设置，否则不建议开启 Per-Monitor 的 DPI 感知；
系统版本在 Windows 10 (1703) 或以上，V2 的感知级别才会生效，否则就是第一个版本。

这里我们其实偷懒了，这种写法方便我们仅处理两种不同的 DPI 缩放规则：

Windows 10 (1703) 之后的系统，全按最全支持来做兼容；
其他系统，全按 Windows 7 的支持级别来做兼容。

你可能注意到本文文末的参考文章中有微软的官方博客，里面推荐的是支持所有级别的 DPI 感知。这看你的需求，因为部分 DPI 相关的模块如果你打算都支持，可能需要更加复杂的判定和计算。本文推荐的少一些，省一点开发量（反正 Windows 8.1 和 Windows 10 早期版本的用户量太少，这部分用户体验不比 Windows 7 差，又不是不能用）。

第一代和第二代的 Per-Monitor 感知之间的差异，可以参考：Windows 下的高 DPI 应用开发（UWP / WPF / Windows Forms / Win32） - walterlv

额外的，如果你的 .NET Framework 版本在 .NET Framework 4.6.2 以下，但操作系统在 Windows 10 及以上，你还需要修改 App.config 文件（在 <configuration /> 节点）。

<runtime>
  <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

注意：

这个值要设为 false。（微软官方吐槽：Yes, set it to false. Double negative FTW!）
AppContextSwitchOverrides 不能被设置两次，如果一已经设置了其他值，需要用分号分隔多个值。

特别说明，当面向 .NET Framework 4.6.2 以下版本编译，但运行于 Windows 10 (1607) 和以上版本时，只需要添加 Switch.System.Windows.DoNotScaleForDpiChanges=false 即可让 WPF 程序处理 Dpi Change 消息，此时 WPF 程序就像高版本的 .NET Framework 中一样能够正常处理多屏下的 DPI 缩放。

以上，划重点 你并不需要编译为高版本的 .NET Framework 即可获得 Per-Monitor 的 DPI 缩放支持。

WPF 程序在特殊清单设置下的效果

-->

▲ 100% DPI

▲ 150% DPI

注意到标题栏（非客户区）没有缩放，而 WPF 区域（客户区）清晰地缩放了。

dpiAwareness 不设置，dpiAware 节点设置为 true：

-->

▲ 100% DPI

▲ 150% DPI

注意到标题栏（非客户区）被缩放了，而 WPF 区域（客户区）被 DPI 虚拟化进行了位图拉伸（模糊）。

dpiAwareness 不设置，dpiAware 节点设置为 true/pm12345：

此时，WPF 程序无法启动！！！而你只需要减少一位数字，例如写成 true/pm1234 即可成功启动，效果跟 true 是一样的，注意效果不是 true/pm。也就是说，/pm 并没有显示出它的含义来。额外的，如果设为 false 但后面跟随那么长的字符串，WPF 程序是可以启动的。

dpiAwareness 设置为 PerMonitorV2：

▲ 150% DPI

注意到标题栏（非客户区）被缩放了，而 WPF 区域（客户区）也能清晰地缩放（仅 Windows 10 1703 及以上系统才是这个效果）。

低版本 .NET Framework 和低版本 Windows 下的 WPF DPI 缩放

由于 Windows 8.1 操作系统用户存量不多，主要是 Windows 7 和 Windows 10。所以我们要么兼容完全不支持 Per-Monitor 的 Windows 7，要么使用具有新特性的 Windows 10 即可获得最佳的开发成本平衡。使用以上的 DPI 缩放方法足以让你的 WPF 应用在任何一个 .NET Framework 版本下获得针对屏幕的 DPI 清晰缩放（Per-Monitor DPI Awareness）。

所以仅针对 Windows 8.1 做特殊的 DPI 缩放是不值得的，把 Windows 8.1 当做 Windows 7 来做那种不支持 Per-Monitor 的处理就好了。当然你硬要支持也有相关文档可以看：Developing a Per-Monitor DPI-Aware WPF Application - Microsoft Docs 了解实现方法。具体是使用 DisableDpiAwareness 特性和 Windows Per-Monitor Aware WPF Sample 中的源码。

参考资料

本文转自 https://blog.youkuaiyun.com/weixin_34239592/article/details/89594661，如有侵权，请联系删除。

1、Windows 下的高 DPI 应用开发（UWP / WPF / Windows Forms / Win32）

本文将介绍 Windows 系统中高 DPI 开发的基础知识。由于涉及到坐标转换，这种转换经常发生在计算的不知不觉中；所以无论你使用哪种 Windows 下的 UI 框架进行开发，你都需要了解这些内容，以免不断踩坑。

本文内容

各种不同的 Windows 桌面 UI 框架
对普通用户而言的 DPI 级别
对 Windows 应用而言的 DPI 感知级别（Dpi Awareness）
不同 UI 框架对 DPI 的支持情况
UWP
WPF
Windows Forms
其他 UI 框架
混合 DPI 感知级别
DPI 相关的 Windows API 的迁移
参考资料

各种不同的 Windows 桌面 UI 框架

微软主推的 Windows 桌面 UI 框架有：

UWP
WPF
Windows Forms
Win32 与 C++
DirectX

后两者实际上并不是 UI 框架，是 UI 框架的底层不同实现。当然你单纯凭借 Win32 和 DirectX 去开发 GUI 应用也没有人拦你，只不过如果你试图只用 Win32 和 DirectX 而不进行各种 UI 组件封装的话，最终会非常痛苦的。

UWP 只支持 Windows 10（当然也分不同的小版本，兼容起来有些痛苦）。

WPF 和 Windows Forms 的最新版本只支持 Windows 7 SP1 及以上系统。如果要支持 Windows 7 和更早的系统，你需要降低 .NET Framework 的版本至 4.6.2 及以下；如果要 XP 支持，还需要到 4.0 及以下。

对普通用户而言的 DPI 级别

DPI 值有两种：系统 DPI (System DPI) 和屏幕 DPI (Monitor DPI)。自 Windows Vista 开始引入系统 DPI 概念，自 Windows 8.1 开始引入屏幕 DPI 概念。

在 Windows Vista / 7 / 8 中，操作系统提供了真正的 DPI 的设置：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ Windows 7 的 DPI 设置（控制面板 -> 外观与个性化 -> 显示）

这里的设置改的就是系统的 DPI 值。

Windows 7 中还额外提供了传统 Windows XP 风格 DPI 缩放比例的选项（此选项在 Windows 8 之后就删掉了），这也是在修改 DPI 值，只不过可以选择非 1/4 整数倍的 DPI 值。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 自定义 DPI 设置

自 Windows 8.1 开始，操作系统开始可以设置不同屏幕的 DPI 值了：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ Windows 10 中的多个屏幕选择

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ Windows 10 中针对每个屏幕的 DPI 设置

如果用户在设置中更改了系统 DPI 值或屏幕 DPI 值，那么 Windows 系统会提示需要注销才会应用修改。

对于 Windows 8.1 以下的系统，注销是必要的。因为系统 DPI 值如果不注销就不会改变，应用需要在系统重新登录后有了新的 DPI 值时才会正常根据新的系统 DPI 值进行渲染。否则就是系统进行的位图缩放。

对于 Windows 8.1 及以上的系统，注销通常也是必要的。虽然屏幕 DPI 值已经更新，并且已向应用窗口发送了 Dpi Change 消息，但系统 DPI 值依然没变。应用必须处理 Dpi Change 消息才会正常渲染。如果应用不支持屏幕 DPI 感知，那么使用的就是系统 DPI 值，于是一样的会被系统进行位图缩放。

但事情到 Windows 10 (1803) 之后，事情又有了转机。现在，你可以通过在设置中打开一个开关，使得无需注销，只要重新打开应用即可让此应用获取到最新的系统 DPI 的值。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

方法是：打开“设置” -> “系统” -> “显示器” -> “高级缩放设置”，在“高级缩放设置”上，打开“允许 Windows 尝试修复应用，使其不模糊”。

额外的，对于 Windows 8.1 及以上的系统，系统 DPI 值等于主屏在系统启动时的屏幕 DPI 值。

对 Windows 应用而言的 DPI 感知级别（Dpi Awareness）

Windows 的 DPI 感知级别经过历代升级，已经有四种了。

无感知 (Unaware)
- DPI 值就是一个常量 96。
- 如果在系统中设置缩放，那么就会采用位图拉伸（会模糊）。
系统级感知 (System DPI Awareness)
- Vista 系统引入
- DPI 值在系统启动后就固定下来，所有显示器上的应用共用这一个 DPI 值。
- 如果在系统设置中修改了 DPI，那么就会采用位图拉伸（会模糊）。
屏幕级感知 (Per-Monitor DPI Awareness)
- 随 Windows 8.1 引入
- 应用的 DPI 值会随着所在屏幕的不同而改变。
- 当多个屏幕 DPI 不一样，而应用从一个屏幕切换到另一个屏幕的时候，应用会收到 DPI 改变的消息
- 只有应用的顶层 HWND 会收到 DPI 改变消息
屏幕级感知第二代 (Per-Monitor V2 DPI Awareness)
- 随 Windows 10 (1703) 引入
- 应用的 DPI 值会随着所在屏幕的不同而改变。
- 当多个屏幕 DPI 不一样，而应用从一个屏幕切换到另一个屏幕的时候，应用会收到 DPI 改变的消息
- 应用的顶层和子 HWND 都会收到 DPI 改变消息
- 以下 UI 元素也会在 DPI 改变时缩放
  - 非客户区（Non-client Area）
  - 系统通用控件中的位图（comctl32V6）
  - 对话框（CreateDialog）

在 Windows 10 19H1 中（对现在来说还是预览版），可以直接在任务管理器中查看到进程的 DPI Awareness：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 在任务管理器中查看 DPI Awareness

方法是在任务管理器中 Details 的标题栏右键，选择列，然后找到 DPI Awareness。

可以看到，目前仅文件资源管理器是 Per-Monitor V2 的。

不同 UI 框架对 DPI 的支持情况

UWP

UWP 当然支持最新的各种 DPI 感知级别，而且是完全支持。

WPF

WPF 的最新版支持最新的 DPI 感知级别，不过依然有限制：

Native WPF applications will DPI scale WPF hosted in other frameworks and other frameworks hosted in WPF do not automatically scale

即原生 WPF 应用支持 DPI 缩放，在其他 UI 框架中的 WPF 也支持 DPI 缩放；但是 WPF 中嵌入的其他 UI 框架不支持自动 DPI 缩放。

WPF 第一个版本（随 .NET Framework 3.5 发布）就已支持系统级 DPI 感知。

.NET Framework 4.6.2 开始的 WPF 才开始支持屏幕级 DPI 感知。而 Per-Monitor V1 和 Per-Monitor V2 的支持在操作系统级别是兼容的，所以只需要修改 WPF 中的应用程序清单即可兼容第二代屏幕级 DPI 感知。

Windows Forms

Windows Forms 也是在 .NET Framework 4.7 才开始支持屏幕级 DPI 感知的。不过部分控件不支持自动随屏幕 DPI 切换。

其他 UI 框架

原生 Win32 是支持最新 DPI 感知的，其他如 GDI/GDI+/MFC 等都不支持，除非开发者手工编写。

混合 DPI 感知级别

当项目足够大的时候，一个或几个项目成员可能很难了解所有的窗口逻辑。让一个进程的所有窗口开启 DPI 缩放对应用的高 DPI 迁移来说比较困难。不过好在我们可以开启混合 DPI 缩放。

Windows 10 (1604) 开始引入顶级窗口（Top-level Window）级别的 DPI 感知，而 Windows 10 (1703) 开始引入每一个 HWND 的 DPI 感知，包括顶级窗口和非顶级窗口。这里的顶级窗口指的是没有父级的窗口，指的是 Parent，而不是 Owner。

在创建一个窗口的前后分别调用 SetThreadDpiAwarenessContext 函数可以让创建的这个窗口具有单独的 DPI 感知级别。前一次是为了让窗口在创建时有一个对此线程的新的 DPI 感知级别，而后一次调用是恢复此线程的 DPI 感知级别。

关于混合 DPI 感知级别的其他内容，可以阅读官网：Mixed-Mode DPI Scaling and DPI-aware APIs - Microsoft Docs。

微软的 Office 系列就是典型的使用了混合 DPI 感知级别的应用。在以下实验中，我组成了一个 96 DPI 的主屏和 144 DPI 的副屏，先在 96 DPI 的屏幕上截一张图，再将窗口移动到 144 DPI 的屏幕中再截一张图。

Microsoft PowerPoint 使用的是系统 DPI 感知级别：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 96 DPI 下的主界面

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 144 DPI 下的主界面

你可以通过点开图片查看原图来比较这两幅图在原图尺寸下的模糊程度。

Microsoft PowerPoint 的演示页面使用的是屏幕 DPI 感知级别：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 96 DPI 下的演示页面

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 144 DPI 下的演示页面

可以看到，演示页面在多屏 DPI 下是没有产生缩放的模糊，即采用了屏幕 DPI 感知级别。

而以上的主界面和演示页面属于同一个进程。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
▲ 只有一个 PowerPoint 进程

DPI 相关的 Windows API 的迁移

GetSystemMetrics -> GetSystemMetricsForDpi
AdjustWindowRectEx -> AdjustWindowRectExForDpi
SystemParametersInfo -> SystemParametersInfoForDpi
GetDpiForMonitor -> GetDpiForWindow

参考资料

本文转自 https://www.cnblogs.com/walterlv/p/10236405.html，如有侵权，请联系删除。

2、WPF中DPI的问题

先搞清楚一下几个概念：

DPI**：**dots per inch ,每英寸的点数。我们常说的鼠标DPI，是指鼠标移动一英寸的距离滑过的点数；打印DPI，每英寸的长度打印的点数；扫描DPI，每英寸扫描了多少个点。（更多请参考百度百科http://baike.baidu.com/view/49853.htm）
**像素：**pixel，picute和element的缩写。像素可以简单的理解为DPI里面的点。例如，显示器的分辨率为1024像素*768像素，就是说显示器的横向可显示1024个点（像素），纵向科研可以显示768个点（像素）。有的显示器每个显示点排列的比较紧密，1英寸的长度内可以排列的点就多一些，有的排列比较疏松，点就少一些，所以像素和英寸之间是没有直接的关系。（更多请参考百度百科http://baike.baidu.com/view/575.htm）
**分辨率：**如上例，但是我们常说调整一下显示器的分辨率，是啥意思呢？显示器有一个自然的分辨率，就是显示器的最大能耐，比如说，显示器的自然分辨率为1600*1200，那么长度小于1600、宽度小于1200的分辨率都可以显示的，1900*1300这样子的分辨率就不行。
**Set Custom Text Size(DPI)****：**WIN7这个DPI我个人觉得，和上述的DPI不是一回事，不知道为啥微软把这个东东也叫DPI。首先，显示设备的物理DPI是不太可能改变的；其次，朋友们发现，这个DPI的默认值是96，也就是1英寸打印96个像素，当我们把DPI调整为125后，1英寸打印125个点。我们的大多数应用程序界面是按照96DPI设计的，到了125DPI后，1英寸的长度不再是1英寸，应该小一点，实际上，没有变小，反而变大了，所以，我觉得和上述的dpi不是一回事，最起码不是改变物理DPI

WPF单位

WPF窗口和所有之内的元素都是使用“独立设备单位”进行测量的。一个独立设备单位被定义为一英寸的96分之一。要理解它在实际应用中的含义，需要考虑一个例子。

假设你在WPF中创建了一个96×96单位大小的按钮，如果你使用的是标准的Windows DPI设置（96dpi），那么每一个独立设备单位对应一个实际的物理象素。这是因为WPF采用如下的计算方式：

[物理单位大小]=[独立设备单位大小] × [系统DPI点数]

                   =1/96 英寸 \* 96 点每英寸

                   = 1 象素

本质上，WPF假定使用96个象素来组成一英寸是通过Windows的系统DPI的设置而获得的。无论如何，实际值取决于你的显示设备。

举例来讲，一个20英寸的液晶显示器的最大分辨率是1600×1200象素。通过下面的简单计算，就可以计算出这个显示器的象素密度。

[系统每英寸点数]=Sqrt(1600×1600 ＋1200×1200) 象素 /19 英寸 (Sqrt为开根号)

                      =100点每英寸

这种情况下的象素密度是100dpi，这实际上比Windows假定的值要高一些。结果，这个显示器按96×96象素显示的按钮比一英寸要小一些。

另一方面，15英寸的液晶显示器的分辨率为1024×768，它的象素密度降到了大约85dpi每英寸，所以96×96的按钮实际上比一英寸要大一些。

这两种情形中，如果减少屏幕尺寸(选择800×600分辨率)，按钮会相应成比例的变大，这是因为系统的DPI设置仍然是96dpi的缘故。换句话说，Windows仍然假定使用96象素大小作为一英寸。即使在分辨率较低，象素数已经远远少了很多的情形下。

系统DPI

目前为止，WPF的按钮工作原理和应用程序中的其他用户界面元素的工作原理是严格一致的。不同的是在你改变系统DPI设置时的结果。在早期的Windows中，这个特性偶尔被称之为“大字体”。这是因为系统DPI影响了系统字体的大小，但是其他细节却没有甚么改变。

这恰恰是WPF不同的地方。WPF考虑系统特有的DPI设置，如果将系统DPI改为120dpi，WPF会假定它需要120个象素去填充一英寸的空间。WPF使用如下的计算去得出如何将逻辑单位转换为物理设备的象素。

[Physical Unit Size]= [独立设备单位尺寸]×[系统DPI]

            ＝1/96 英寸 ×120 dpi

            ＝1.25 象素

换句话说，当你设置系统DPI为120dpi的时候，WPF渲染引擎假定一独立设备单位等于1.25象素大小。如果显示一个96×96的按钮，物理尺寸实际上是120象素×120象素，这是期待中的结果――一个在标准显示器中显示为一英寸的按钮，在更高象素密度的显示器中仍然显示为一英寸。

这种自动缩放的功能如果只被应用到按钮中，则实际上是没有多大用处的。但是WPF使用独立设备单位来显示所有的东西，包括形状，控件，文本和放进窗体中的任何元素。结果，系统的DPI可以被更改为任何需要的值，WPF会自动无缝的调整应用程序的尺寸。如何更改DPI取决于所用的系统，具体步骤就不赘述了。

位图与矢量图

当使用普通的控件时，可以利用WPF的分辨率的独立性。WPF会自动关注所有的控件以保证它们都有正确的尺寸。可是，如果你想将图片合并到你的应用程序，那就不能够漫不经心了。举例来说，在传统的应用程序中，开发人员使用很小的位图到工具条指令。在WPF应用程序中，这种方式却不理想，因为会根据系统的DPI的设置而放大和缩小，位图有可能显示的很模糊。取而代之，在设计WPF应用程序界面时，即使最小的图标也通常设计为矢量图。矢量图被定义为一个图形集，正因为如此，它们可以被缩放到任意尺寸大小。

很难去高估分辨率独立性的重要性。乍看起来它是一个简单的（straightforward）的一流的(elegant)解决方案，解决了一个历史悠久的问题。然而，为了设计的用户界面能够富有弹性。开发人员需要一种新的思维方法。

–=华丽分隔符===========

WPF程序中的单位是与设备无关的单位，每个单位是1/96英寸，如果电脑的DPI设置为96(每个英寸96个像素)，那么此时每个WPF单位对应一个像素，不过如果电脑的DPI设备为120(每个英寸120个像素)，那此时每个WPF单位对应应该是120/96=1.25个像素

一般在程序中我们常常需要得到当前屏幕的宽和高，常见做法有：

1.System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width

System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height

这两个方法可以返回当前屏幕选择的分辨率，该分辨率是以像素为单位，在DPI为96的情况下我们可以利用它们来做一些控件的定位，因为此时WPF单位对应一个像素，而当DPI非96的情况下，用该分辨率来做定位就会发现误差了，因此此时每个WPF单位并不是对应于一个像素

2.SystemParameters.PrimaryScreenWidth

SystemParameters.PrimaryScreenHeight

这两个方法可以返回当前屏幕的宽和高,它是与设备无关的单位(1/96英寸)，因此用它来做控件的定位，在DPI改变的情况下，也不会发生定位上的误差

3.SystemParameters.WorkArea.Size.Width

SystemParameters.WorkArea.Size.Height

这两个方法可以返回当前屏幕工作区的宽和高(除去任务栏),它也是与设备无关的单位，通常我们可以结合2和3来得到任务栏的高度

–=华丽分隔符===========

WPF单位真的与分辨率无关吗？

WPF从发布之日起，一直将“分辨率无关(resolution independence)”作为其亮点，声称使用WPF制作的用户界面在轻巧的Ultra-Mobile PC的屏幕上和在50英寸的电视机上都能很好地显示。微软之所以称WPF具备“分辨率无关”这一特性，主要是因为WPF的坐标单位设计成为以1/96英寸为一个逻辑像素单位，而不是与设备相关的像素单位。

但是微软本身对WPF“分辨率无关”这一特性没有作更多的具体解释，导致用户会产生很多误解。

误解之一

改变显示器的分辨率设置，同一个WPF的用户界面和绘制的图形尺寸不会变化。

这个可以用一个非常简单的实验证明该结论是错误的。新建一个WPF应用程序窗口，其中高度为400DIUs（DIU：Device independent unit，设备无关单位），宽度为600DIUs，让这个窗口分别在分辨率设置为1280 * 1024和800*600的环境下运行，如下图所示，两个窗口的尺寸是明显不一样的。

误解之二

改变显示的DPI设置，同一个WPF的用户界面和绘制的图形尺寸不会变化。

显示的DPI设置，在XP系统下是通过右键——属性——设置选项卡——高级，可以调用出来，如下图所示：

图 2 显示属性DPI设置

这个也可以用同样的方法进行证明该结论是错误的。仍然是高度为400DIUs[1]，宽度为600DIUs的窗口分别运行在96DPI和192DPI两种设置环境下。从下图也可以明显看出窗口的尺寸是不一样的。

误解之三

在不同屏幕上，如果DPI设置相同，则同一个WPF的用户界面和绘制的图形尺寸不会变化。

在这个地方有必要对屏幕的DPI设置进行一下解释说明。DPI设置是指屏幕上每英寸多少个像素，比如当前设置为96DPI，即屏幕上96个像素为1英寸。一般的Windows XP系统有正常尺寸（96DPI）、大尺寸（120DPI）和自定义尺寸三种选项。既然WPF的坐标单位是以1/96英寸为一个逻辑像素单位，那么我们有理由相信，如果两个显示器的DPI设置是相同的，那么同一个WPF的用户界面和绘制的图形尺寸不会变化。很遗憾，这样的结论依旧是一个错误。

CalvinP.Schrotenboer 也用一个实验证明这是一个错误。实验环境如表 1，比如桌面LCD显示器实际屏幕宽度和高度（像素单位）为1600 x 1200，这个和普通的分辨率设置需要区分，这是显示设备的最大分辨率或者说是物理分辨率，即物理上该显示器屏幕上是1600 x 1200个像元，英文中又称这种分辨率为“native resolution（原生分辨率）”。由于两个屏幕物理尺寸也不一样，所以实际的物理DPI可以通过表中的计算公式得到。实际的物理DPI和操作系统的DPI设置是没有什么联系的。

表 1实验环境

实验环境	系统一	系统二
显示器类型	桌面LCD显示器	笔记本LCD显示器
屏幕宽度和高度（像素单位）	1600 x 1200	1400 x 1050
屏幕宽度和高度（英寸单位）	17.0 x 12.75	12.0 x 9.0
实际的物理DPI	纵向：1600 / 17.0 = 94DPI 横向：1200 / 12.75 = 94DPI	纵向：1400 / 12 = 117DPI 横向：1050 / 9 = 117DPI
操作系统的DPI设置	96DPI	96DPI

在两个不同系统当中运行同一个WPF应用程序，该程序了绘制了一条长为384DIUs的直线，换算成英寸即为384/96= 4英寸。结果在两个系统当中的实际尺寸如下图所示：

问题出在哪儿了？

其实从表 1当中就能看出一些端倪，原因正是在于实际的物理DPI和操作系统设置的DPI不一致造成的。WPF无法知道当前使用设备实际的物理DPI为多少，相反通过操作系统的API函数获得操作系统的DPI值，然后简单地认为这就是实际的物理DPI值。比如在桌面LCD显示器上，实际一个物理像元的尺寸为1/94英寸，由于操作系统设置为96DPI，因此WPF还固执地以为一个实际的像元为1/96英寸，因此线段长度为1/94 * 384 = 4.08英寸。笔记本显示器实际一个物理像元的尺寸为1/117英寸，因此线段长度为1/117 * 384 = 3.28英寸。这个值和我们测量的结果正好相符。

那么我们有理由推测，如果将操作系统的DPI设置成实际的物理DPI，则能做到真正的“分辨率独立”，即在两个不同显示器上显示的线段长度都为4英寸，如图 5所示：