对 Windows Vista 和 Windows 7 中的 DPI 虚拟化和 DPI 感知应用程序进行故障排除

Question

我遇到一个问题，应用程序（用 Delphi 编写）在所有系统上的默认 96 DPI 设置下表现正常，但在不同系统上的“150% 文本大小”（内部 144 dpi）设置下表现不一致。似乎在某些系统上，我的应用程序的某些文本/字体部分正在被拉伸，而在其他系统上，它们则没有。我本以为我的应用程序在特定版本的 Windows (Win7) 上、在特定的 DPI 下应该具有相同的行为方式。

我的应用程序要么让 Windows 知道它不需要 DPI 虚拟化功能，要么就不需要。我就明白这么多了。我不明白的是 DPI 的变化如何导致两台机器上的外观不同，两台机器都运行 Windows 7，分辨率均为 144 dpi，以相同的固定尺寸显示相同的字体和表单。

DPI 虚拟化中是否存在一些我需要在 Windows 中检查的依赖于配置的元素（注册表等）？否则，您如何排除故障并了解 DPI 虚拟化是否正在客户端窗口上完成？

在 Delphi 中，如果不想缩放，则必须将 TForm.Scaled 属性设置为 false。但我不明白的是，当主窗体的 Scaled 属性为 true 时，我不能总是预测结果。

在我的应用程序中，最让我困惑的是，我有一个控件，它只在我的大型实际应用程序中表现不佳，但在我试图调试该控件的独立应用程序中却不会表现不佳。为了了解独立应用程序中的控制行为，我被迫制作一个演示应用程序，在其中通过清单文件强制 DPI 感知。然后我可以重现控制绘图故障，尽管形式不同。

这是我在演示应用程序中使用的清单文件，它暴露了我的控件在处理 Windows 中的高 dpi 设置时遇到的问题。 可能会

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <asmv3:windowsSettings
         xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
  <assemblyIdentity version="14.0.3615.26342" processorArchitecture="*"            
   name="TestProject" type="win32"></assemblyIdentity>
  <description>High DPI Controls Test App</description>
</assembly>

然而，我发现的一件奇怪的事情是，当我在应用程序中禁用 DPI 虚拟化时，应用程序中的控件 出现混乱，这里是大约 30 个地方之一的示例。通过关闭我表单中的 Scaled 属性解决了这个特殊的问题。但在其他地方， TForm.Scaled=false 会导致问题，而在某些形式中，它会修复它：

更新：事实证明，我的一些控件使用 GDI+，并且 GDI+ 上下文中的字体行为与正常 GDI 上下文中的字体行为不同，至少对于某些第三方- 使用 GDI+ 的派对控件。这是令人头痛的一个主要原因。其次，VCL 中对于 DPI 感知的测试覆盖率参差不齐，且要求定义不明确。一些 VCL 控件基于 MS 通用控件，虽然可以公平地说，底层通用控件可能在高 DPI 情况下工作正常，但并非所有 VCL 控件包装器都能保证正确工作。因此，检查应用程序的所有控件是否具有高 DPI 意识，以及所有可用 Windows 7 主题中的正确行为：

1. 航空玻璃打开，96dpi（大多数现代硬件上的默认 Win7 外观）
2. 基本主题（航空玻璃关闭）但是xp主题启用了
3. 经典的win2000外观（玻璃关闭），以及xp级别主题，
4. 高对比度白色
5. 高对比度黑色
6. 各种其他96-DPI设置

..这样的例子不胜枚举.，你的负担相当沉重，作为应用程序开发人员。无论您是使用 VCL 的 delphi 用户，还是 MFC/ATL C++ 开发人员，在我看来，支持所有各种古怪的 Windows 模式都是一个几乎难以承受的负担。所以大多数人都不会打扰。我说得对吗？

Answer 1

您需要通过如下部分来表明您的应用程序支持 DPI：

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

如果您这样做，那么您将无法获得 DPI 虚拟化。

你不应该使用 DPI 虚拟化，所以我认为尝试弄清楚它是如何工作的没有什么意义。它很容易依赖于显卡驱动程序。我们几乎不可能解释为什么虚拟化会这样：您甚至没有提供任何屏幕截图、硬件详细信息等。但是，您根本不应该费心去诊断这一点。显示为 dpiaware，这不是问题。

作为参考，我为您提供：

• 编写高 DPI Win32 应用程序< /a>
• http://www.rw-designer.com/DPI-aware

Answer 2

这实际上是一个不同的问题。

您的表单不应该随着用户的DPI而变大，而应该随着字体大小而变大。

Delphi 的默认表单字体是8pt Tahoma。
平均 8pt Tahoma 字符为：6.08px * 13px。

从 Windows Vista 开始，默认字体为 9pt Segoe UI。
平均 9pt Segoe UI 字符为：6.81px * 15 像素。

您的 Windows 应用程序应该尊重用户的字体首选项（即 IconTitleFont）。

我的 Windows 字体首选项是 12pt Segoe UI，其平均字符大小为：8.98px * 21px:

这意味着如果您在 Tahoma 8pt您的表单>（13px 高），您需要将窗体和所有子控件缩放 162%：

scaleFactor = (userFontSize / designedFontSize)
            = 21px / 13px
            = 1.615

---

如果您细心，您会注意到更改 DPI 只是更改字体大小的一种特殊情况。您的 8pt 字体仍然是 8pt，但 8pt 会转化为更多像素。如果您运行 131dpi（Windows 7 中的 136% 缩放设置），则：

9pt Segoe UI,  96dpi = 6.81px x 15px
9pt Segoe UI, 131dpi = 8.98px x 21px

注意：我选择 131dpi 和 12pt 作为示例并非巧合。在工作中，我运行 96dpi 但 12pt。在家里我运行 9pt 但 131dpi。两者具有相同的像素字体高度，21px。

---

最后，您需要根据大小差异调用 ScaleControl：

procedure StandardizeFormFont(Form: TForm);    
var
   iconTitleFontName: string;
   iconTitleFontSizePixels: Integer;
   currentFontSizePixels: Integer;
begin
   GetIconTitleFont(iconTitleFontName, iconTitleFontSizePixels);

   //Change font face first
   //Some fonts are inheriently taller than others
   //(even at the same point size)
   Form.Font.Name := iconTitleFontName;     

   //Get the form's current font height (in pixels)
   currentFontSizePixels := Form.Font.Height; //negative number, but so is iconTitleFontSizePixels

   Form.ScaleBy(iconTitleFontSizePixels, currentFontSizePixels);
end;

实际上，这段代码非常简单。许多子控件需要手动更新：

• 列表视图列需要
• 使用 ParentFont = false 获得更宽的控件，需要调整其字体，
• TImage 控件需要将其图像拉伸到新尺寸，
• 工具栏需要使用更大的图像

实际上，我们使用 StandardizeFormFont 的超级版本，它递归地遍历表单上的所有控件，并最好根据每个控件的内容调整每个控件。

Delphi 的每个控件都应该重写它的 ScaleControl 方法，并进行所需的调整：

protected
   procedure ChangeScale(M, D: Integer); override;

Answer 3

“自定义 DPI 设置”窗口具有“使用 Windows XP 样式 DPI 缩放”。这可能可以解释不同的行为。

Answer 4

事实证明，当系统 DPI 更改为默认的 96 dpi 值时，我的应用程序中的怪癖主要分为三个阵营：

1. 应用程序的某些控件使用 GDI，某些控件使用 GDI+。 GDI 和 GDI+ 字体在不同 DPI 下的呈现方式存在一些差异，至少在我使用的控件中是这样。

2. 我在delphi中使用一个名为VCL的框架。在这个Delphi VCL框架中，有些表单TForm.Scaled=true，有些表单TForm.Scaled=false。因为它要求您以缩放形式考虑每个控件，所以作为 UI 设计师，您经常会发现缩放形式“丑陋”或不可接受。关闭“缩放”后，您留下的表单要么被 Windows 7 本身在高 DPI 设置（DPI 虚拟化模式）下拉伸，要么显得很小，因此，如果您愿意，可以忽略用户的“请求”，以获得 144 dpi 版本的表单您的 96 dpi 用户界面。其他人可能正在使用其他语言的其他框架，或者甚至可能使用非常老式的东西，例如 Visual C++ 的对话框编辑器，您可以在“对话框单元”中设计对话框，这是尝试分离常规对话框的另一种方法布局，从 1:1 对应到像素。缩放、拉伸和布局控件是 UI 设计的常见部分，必须以符合平台要求的方式来解决。就我而言，VCL 做得很好，让我设计了一个支持 96 DPI 的玻璃航空应用程序，并且在其他 DPI 等级下也能很好地工作，但我的大多数自定义控件却不能。因此，坚持使用 VCL 附带的控件的另一个原因是：如果您关心高 DPI 支持，那么当您尝试使高 DPI 支持起作用时，您的工作就会变得更加困难。

3. DPI 虚拟化又由您必须明确包含在应用程序中的清单设置控制。由于我的应用程序已经有一个自定义清单（不是当您单击项目设置中的 Enable-windows-themes 复选框时包含在 Delphi 应用程序中的清单），我能够再次打开和关闭此 DPI 虚拟化，并进行测试我在这两种情况下的申请。我发现我的应用程序在没有 DPI 虚拟化的情况下无法运行，因此我将 Windows 保留为其默认行为。其他人的应用程序可能会轻松地在禁用 DPI 虚拟化的情况下工作，如果他们使用 100% vcl 控件，并且表单使用表单缩放或其他一些技术，以在各种情况下适当调整自身大小（例如 DevExpress 的 VCL ExpressLayout 控件）。字体大小和 DPI 间距。）。在我看来，最终VCL的功能已经足够了，但对于真正具有工业强度的解决方案，需要比VCL更先进的框架，才能全面正确地处理“高DPI环境”等问题，并且在这些情况下，第三方控件的设计通常无法达到当前 VCL 的效果。这种框架问题在 WPF 框架 (Microsoft) 和 Java (wing) 中非常明显，但不是 VCL 的经典“Win16/Win32 通用控制框架”的一部分。

总而言之，这些变化与过去相比并没有那么不同（复杂），当时 Windows XP 和其他版本的 Windows 为您提供了“字体大小”的选择，而现在，Windows 7 UI 体验试图掩盖字体点大小选项非常深入，而是为您提供了一个“文本大小”更改用户界面，可以修改表面以下的系统 DPI。这两种改变用户体验的方法都会导致几乎每个用户都遇到至少一个主要商业应用程序的问题，该应用程序在所产生的更改中看起来无法正常工作。随着超高点距显示器在消费类 PC 领域变得越来越普遍，这个问题可能会变得越来越严重，并且需要围绕更合适的框架进行 UI 设计。