在 .NET WInForms 中，什么可能会导致 64 位 Vista 上出现重画问题，但不会出现 32 位重画问题？

Question

当针对 Any Cpu 进行编译以及编译至 x86 时，会发生这种情况。 GUI 的部分不会重绘，除非调整大小，例如，如果主窗体最大化，则某些控件不会随之调整大小，而其他部分则不会重绘并显示之前的内容。

这在 32 位机器（XP 和 Vista）上工作正常，但在 64 位 Vista（没有 x64 XP 来测试）上，重绘无法正常工作。

有人知道从哪里开始追踪这个问题吗？

编辑：这种情况发生在两台独立的机器上，至少我当前使用的机器具有 NVidia 的最新驱动程序。

Edit2：在我的 64 位计算机上运行 32 位 XP 虚拟机，并且应用程序没有在 VM 中出现重绘问题

Edit3：这可能是驱动程序问题，但我们不知道驱动程序是否或何时会修复问题。 一位同事说，家里使用 ATI 卡的问题比使用 NVidia 的要少，但过去几个月我几乎每月都会更新我的视频驱动程序，但问题仍然没有解决，所以我们不能只是发布我们的产品并告诉我们的客户，有一天驱动程序制造商可能会抽出时间来解决这个问题。

有谁知道应该避免哪些事情？ 我们编译为 x86，并且所有组件都是 x86。 我似乎无法使用测试项目中的任何组件重现此问题，并且我没有听到其他人在大多数组件论坛上报告这些问题，因此很可能这是我们正在做的事情。

Answer 1

这听起来非常像 这个问题。

在 Windows 上调整窗口大小时，您通常会得到一个链，其中每个窗口接收 WM_SIZE 消息，然后对其子窗口调用 MoveWindow() （或类似），而子窗口又接收 WM_SIZE 消息。代码>WM_SIZE等等。 我确信 .NET 在幕后也做了同样的事情。

在 x64 上，Windows 限制了这种嵌套的深度，并且在某个点（12-15 个嵌套窗口）之后，它将不再发送 WM_SIZE 消息。 x86 上似乎不存在此限制。 此限制会影响在 x64 版本的 Windows 上运行的 x86 和 x64 代码。

这让我们困扰了很长时间，因为不同的 x64 安装会显示不同的症状。 上面的 MSDN 博客文章有一些可能的解决方法 - 我们最终使用辅助线程来异步调整窗口大小，这相当巧妙地解决了问题。

Answer 2

如果您使用的是 Windows 窗体，则可能与 Windows 64 位上的嵌套限制问题有关。

详细信息请参见：http://www.feedghost.com/Blogs/BlogEntry.aspx ?EntryId=17829

总之...

来自 MS 源，在 Control.SetBoundsCore 中：

SafeNativeMethods.SetWindowPos(new HandleRef(window, Handle), NativeMethods.NullHandleRef, x, y, width, height, flags);

// NOTE: SetWindowPos causes a WM_WINDOWPOSCHANGED which is processed
// synchonously so we effectively end up in UpdateBounds immediately following
// SetWindowPos.
//
//UpdateBounds(x, y, width, height);

以及来自 MSDN：

http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/25181bd5-394d-4b94- a6ef-06e3e4287527/

“一项小调查表明 Windows 停止发送 WM_SIZE
当它达到某个特定的嵌套时
等级。 换句话说，它不会发送
WM_SIZE 到您的子窗口，如果您
处理时尝试调整它们的大小
父级中的 WM_SIZE。 取决于
关于用户内容/更新/服务
包装最大嵌套级别为
它可能会停止传播 WM_SIZE
从 15 到 31 不等，甚至更多
更高（实际上无法到达）
最新的 XP 32bit/sp2。

但在 XP x64 下它仍然太少了，而且仍然有一些类似的丑陋的东西
发生在某些情况下的其他消息
Vista 的构建。

所以这肯定是一个 Windows 错误。”

您有两个选择：要么减少控件层次结构的深度（更理想的解决方案），要么从您使用的每个系统控件中派生“固定”控件，如下所示：

public class FixedPanel : Panel
{
  protected override void SetBoundsCore( int x, int y, int width, int height, BoundsSpecified specified )
  {
    base.SetBoundsCore( x, y, width, height, specified );

    if( specified != BoundsSpecified.None )
    {
      if( ( specified & BoundsSpecified.X ) == BoundsSpecified.None )
      {
        x = Left;
      }
      if( ( specified & BoundsSpecified.Y ) == BoundsSpecified.None )
      {
        y = Top;
      }
      if( ( specified & BoundsSpecified.Width ) == BoundsSpecified.None )
      {
        width = Width;
      }
      if( ( specified & BoundsSpecified.Height ) == BoundsSpecified.None )
      {
        height = Height;
      }
    }

    if( x != Left || y != Top || width != Width || height != Height )
    {
      UpdateBounds( x, y, width, height );
    }
  }
}

Answer 3

我认为此问题最可能的原因是应用程序中的重绘问题。 64 位上可能存在细微的 Windows 消息排序差异，从而在您的代码中暴露了此问题。

您可以通过执行以下操作来进行实验。

1. 向您的应用程序添加一个计时器。
2. 在事件处理程序调用 flakyControl.Update() 中，

我将计时器设置为 5 秒之类的长值。 然后在 Win64 上运行该应用程序，看看是否可以解决问题。 如果是这样，那么最可能的原因是您的控件之一没有正确发出其已失效的信号。

我将从应用程序中的任何自定义控件开始。 系统地向代码中的每个重写方法和事件处理程序添加 Update 调用。 最终你会找到解决问题的方法，然后你就会知道错误到底在哪里。

Answer 4

如果您使用 MSDN 上描述的 BeginInvoke() 解决方案 blog 确保禁用覆盖 OnSizeChanged() 的控件子级的停靠。 我有 Dock = DockStyle.Fill，并且必须更改为 DockStyle.None 才能使修复工作。

Answer 5

对我来说听起来像是显示驱动程序问题...

尝试更新到最新的驱动程序，看看是否可以解决问题？ 64/32 位的差异可能是转移注意力的......

Answer 6

我同意戈登的观点。 我见过这样的问题：全新的 64 位机器出现显示问题，而程序在 32 位下看起来很好，但在 64 位机器上会出现奇怪的问题。 更新到最新/推荐的驱动程序几乎总能解决问题。

Answer 7

事实上，您可以在虚拟操作系统上运行该程序而不会出现任何问题，这表明这是一个驱动程序问题，因为（至少在 VirtualPC 中）显卡是模拟的。 这意味着显卡通常处理的一些事情现在由 CPU 完成，因此不与显卡驱动程序交互。 请注意，我不是虚拟化方面的专家，我认为虚拟化层可能会以其他方式影响该问题。

Answer 8

我相信这与树中嵌套的 HWND 的数量有关。 我不知道具体细节，但 64 位的嵌套 HWND 有一些限制。 当我看到这种情况发生时，我会通过从完整的 vista basic（或 aero）主题退回到 windows classic 来解决它。 此时问题就消失了。

尝试切换到经典，如果可以解决问题，看看是否可以减少嵌套 HWND 的数量。