当用户调整对话框大小时，如何强制窗口不重绘对话框中的任何内容？

Question

当用户抓住可调整大小的窗口的一角，然后移动它时，窗口首先移动窗口的内容，然后向正在调整大小的窗口发出 WM_SIZE。

因此，在一个对话框中，我想要控制各种子控件的移动，并且想要消除闪烁，用户首先看到 Windows 操作系统认为窗口的样子（因为，AFAICT，操作系统使用 bitblt 方法来移动在发送 WM_SIZE 之前，窗口内的事物） - 只有然后我的对话框才能处理移动其子控件，或调整它们的大小等，之后它必须强制重新绘制事物，这现在会导致闪烁（至少）。

我的主要问题是：有没有办法强制窗口不做这种愚蠢的 bitblt 事情？如果窗口的控件随着窗口大小的调整而移动，那么它肯定是错误的，或者当它们的父级调整大小时，它们也会调整自己的大小。不管怎样，让操作系统进行预绘制只会搞砸工作。

我一度认为这可能与 CS_HREDRAW 和 CSVREDRAW 类标志有关。然而，现实情况是，我不希望操作系统要求我擦除窗口 - 我只想自己重新绘制，而不需要操作系统首先更改窗口的内容（即我希望显示是原来的样子）在用户开始调整大小之前 - 没有来自操作系统的任何位块传输）。而且我也不希望操作系统告诉每个控件它需要重新绘制（除非它恰好是实际上因调整大小而被遮盖或显示的控件）。

我真正想要的是：

1. 移动和调整子控件的大小<在屏幕上更新任何内容之前，
2. 子控件，以便它们在新的大小和位置上不出现任何瑕疵。
3. 完全绘制所有已移动或调整大小的 。

2 和 3 可以颠倒过来

注意：当我将 DeferSetWindowPos() 与标记为 WS_CLIPCHILDREN 的对话框资源结合使用时，

步骤 我可以对内存 DC 执行上述操作，然后只在 WM_SIZE 处理程序的末尾执行一个 bitblt

我已经使用了一段时间了，但我无法逃脱两件事：

1. 我仍然无法逃脱。禁止 Windows 执行“预测性 bitblt”答案：请参阅下面的覆盖 WM_NCCALCSIZE 来禁用此行为的解决方案。

2. 我看不出如何构建一个对话框，其中的子控件绘制到双缓冲区。 答案：请参阅下面 John 的答案（标记为答案），了解如何要求 Windows 操作系统对对话框进行双缓冲（注意：根据文档，这不允许在绘制操作之间进行任何 GetDC() 操作）。

---

我的最终解决方案（感谢所有做出贡献的人，尤其是 John K.）：

经过大量的汗水和泪水，我发现以下技术无论在 Aero 和 XP 中还是在禁用 Aero 的情况下都可以完美地工作。轻弹是不存在的(1)。

1. 挂钩对话框过程。
2. 覆盖 WM_NCCALCSIZE 以强制 Windows 验证整个客户区，而不是 bitblt 任何内容。
3. 覆盖 WM_SIZE 来完成所有的移动和操作。使用 BeginDeferWindowPos/DeferWindowPos/EndDeferWindowPos 调整所有可见窗口的大小。
4. 确保对话框窗口具有 WS_CLIPCHILDREN 样式。
5. 不要使用 CS_HREDRAW|CS_VREDRAW（对话框不使用，所以通常不是问题）。

布局代码由您决定 - 在布局管理器的 CodeGuru 或 CodeProject 上很容易找到示例，或者推出您自己的示例。

以下是一些代码摘录，应该可以帮助您大部分了解：

LRESULT ResizeManager::WinProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
    switch (msg)
    {
    case WM_ENTERSIZEMOVE:
        m_bResizeOrMove = true;
        break;

    case WM_NCCALCSIZE:
        // The WM_NCCALCSIZE idea was given to me by John Knoeller: 
        // see: http://stackoverflow.com/questions/2165759/how-do-i-force-windows-not-to-redraw-anything-in-my-dialog-when-the-user-is-resiz
        // 
        // The default implementation is to simply return zero (0).
        //
        // The MSDN docs indicate that this causes Windows to automatically move all of the child controls to follow the client's origin
        // and experience shows that it bitblts the window's contents before we get a WM_SIZE.
        // Hence, our child controls have been moved, everything has been painted at its new position, then we get a WM_SIZE.
        //
        // Instead, we calculate the correct client rect for our new size or position, and simply tell windows to preserve this (don't repaint it)
        // and then we execute a new layout of our child controls during the WM_SIZE handler, using DeferWindowPos to ensure that everything
        // is moved, sized, and drawn in one go, minimizing any potential flicker (it has to be drawn once, over the top at its new layout, at a minimum).
        //
        // It is important to note that we must move all controls.  We short-circuit the normal Windows logic that moves our child controls for us.
        //
        // Other notes:
        //  Simply zeroing out the source and destination client rectangles (rgrc[1] and rgrc[2]) simply causes Windows 
        //  to invalidate the entire client area, exacerbating the flicker problem.
        //
        //  If we return anything but zero (0), we absolutely must have set up rgrc[0] to be the correct client rect for the new size / location
        //  otherwise Windows sees our client rect as being equal to our proposed window rect, and from that point forward we're missing our non-client frame

        // only override this if we're handling a resize or move (I am currently unaware of how to distinguish between them)
        // though it may be adequate to test for wparam != 0, as we are
        if (bool bCalcValidRects = wparam && m_bResizeOrMove)
        {
            NCCALCSIZE_PARAMS * nccs_params = (NCCALCSIZE_PARAMS *)lparam;

            // ask the base implementation to compute the client coordinates from the window coordinates (destination rect)
            m_ResizeHook.BaseProc(hwnd, msg, FALSE, (LPARAM)&nccs_params->rgrc[0]);

            // make the source & target the same (don't bitblt anything)
            // NOTE: we need the target to be the entire new client rectangle, because we want windows to perceive it as being valid (not in need of painting)
            nccs_params->rgrc[1] = nccs_params->rgrc[2];

            // we need to ensure that we tell windows to preserve the client area we specified
            // if I read the docs correctly, then no bitblt should occur (at the very least, its a benign bitblt since it is from/to the same place)
            return WVR_ALIGNLEFT|WVR_ALIGNTOP;
        }
        break;

    case WM_SIZE:
        ASSERT(m_bResizeOrMove);
        Resize(hwnd, LOWORD(lparam), HIWORD(lparam));
        break;

    case WM_EXITSIZEMOVE:
        m_bResizeOrMove = false;
        break;
    }

    return m_ResizeHook.BaseProc(hwnd, msg, wparam, lparam);
}

调整大小实际上是由 Resize() 成员完成的，如下所示：

// execute the resizing of all controls
void ResizeManager::Resize(HWND hwnd, long cx, long cy)
{
    // defer the moves & resizes for all visible controls
    HDWP hdwp = BeginDeferWindowPos(m_resizables.size());
    ASSERT(hdwp);

    // reposition everything without doing any drawing!
    for (ResizeAgentVector::const_iterator it = m_resizables.begin(), end = m_resizables.end(); it != end; ++it)
        VERIFY(hdwp == it->Reposition(hdwp, cx, cy));

    // now, do all of the moves & resizes at once
    VERIFY(EndDeferWindowPos(hdwp));
}

也许最后的棘手部分可以在 ResizeAgent 的 Reposition() 处理程序中看到：

HDWP ResizeManager::ResizeAgent::Reposition(HDWP hdwp, long cx, long cy) const
{
    // can't very well move things that no longer exist
    if (!IsWindow(hwndControl))
        return hdwp;

    // calculate our new rect
    const long left   = IsFloatLeft()   ? cx - offset.left    : offset.left;
    const long right  = IsFloatRight()  ? cx - offset.right   : offset.right;
    const long top    = IsFloatTop()    ? cy - offset.top     : offset.top;
    const long bottom = IsFloatBottom() ? cy - offset.bottom  : offset.bottom;

    // compute height & width
    const long width = right - left;
    const long height = bottom - top;

    // we can defer it only if it is visible
    if (IsWindowVisible(hwndControl))
        return ::DeferWindowPos(hdwp, hwndControl, NULL, left, top, width, height, SWP_NOZORDER|SWP_NOACTIVATE);

    // do it immediately for an invisible window
    MoveWindow(hwndControl, left, top, width, height, FALSE);

    // indicate that the defer operation should still be valid
    return hdwp;
}

“棘手”我们避免尝试弄乱任何已被破坏的窗口，并且我们不会尝试针对不可见的窗口推迟 SetWindowPos（因为这被记录为“将失败”。

我已经在一个隐藏一些控件并使用相当复杂的布局并取得了巨大成功的真实项目，即使没有 Aero，即使您使用对话框窗口的左上角调整大小（大多数可调整大小的窗口都会显示），闪烁也为零 (1)。 问题 - IE、FireFox 等）。

当你抓住这个句柄时，

大多数闪烁和 ) 请注意，不可能避免在过去的任何东西之上进行抽签。对于对话框中未更改的每个部分，用户看不到任何内容（没有任何闪烁）。但是，如果事情发生了变化，用户就会看到变化 - 这是无法避免的，并且是 100% 的解决方案。

Answer 1

您无法在调整大小期间阻止绘画，但您可以（小心地）阻止重新绘画，这就是闪烁的根源。首先，bitblt。

有两种方法可以阻止 bitblt 的发生。

如果您拥有顶级窗口的类，则只需使用 CS_HREDRAW | 注册它即可。 CS_VREDRAW 样式。这将导致调整窗口大小以使整个客户区域无效，而不是尝试猜测哪些位不会更改并进行位转移。

如果您不拥有该类，但有能力控制消息处理（对于大多数对话框都是如此）。 WM_NCCALCSIZE 的默认处理是处理类样式 CS_HREDRAW 和 CS_VREDRAW 的位置，默认行为是返回 WVR_HREDRAW |当类具有 CS_HREDRAW | WVR_VREDRAW 时，不会处理 WM_NCCALCSIZE CS_VREDRAW。

因此，如果您可以拦截WM_NCCALCSIZE，则可以在调用DefWindowProc之后强制返回这些值，以进行其他正常处理。

您可以收听 WM_ENTERSIZEMOVE 和 WM_EXITSIZEMOVE 来了解窗口大小调整何时开始和停止，并使用它来暂时禁用或修改绘图和/或布局代码的工作方式以尽量减少闪烁。您究竟想要做什么来修改此代码取决于您的普通代码通常在 WM_SIZE WM_PAINT 和 WM_ERASEBKGND 中执行的操作。

当您绘制对话框的背景时，您不需要在任何子窗口后面绘制。确保对话框具有 WS_CLIPCHILDREN 可以解决此问题，因此您已经处理了此问题。

当您移动子窗口时，请确保使用 BeginDeferWindowPos / EndDefwindowPos 以便所有重画同时发生。否则，当每个窗口在每次 SetWindowPos 调用时重新绘制其非客户区域时，您将会看到一堆闪烁。

Answer 2

如果我正确理解了这个问题，这正是雷蒙德今天解决的问题。

Answer 3

这是 2018 年的更新，因为我刚刚经历了和你一样的挑战。

您问题中的“最终解决方案”以及相关答案提到了 WM_NCCALCSIZE 和 CS_HREDRAW|CS_VREDRAW 的技巧，有助于防止 Windows XP/Vista/7 执行以下操作： BitBlt 在调整大小期间干扰您的客户区。提及类似的技巧甚至可能很有用：您可以拦截 WM_WINDOWPOSCHANGING （首先将其传递到 DefWindowProc）并设置 WINDOWPOS.flags |= SWP_NOCOPYBITS >，这会禁用 Windows 在调整窗口大小期间对 SetWindowPos() 进行的内部调用中的 BitBlt。这与跳过 BitBlt 具有相同的最终效果。

有些人提到您的 WM_NCCALCSIZE 技巧在 Windows 10 中不再有效。我认为这可能是因为您编写的代码在应该返回 WVR_ALIGNLEFT|WVR_ALIGNTOP 时返回了 WVR_ALIGNLEFT|WVR_ALIGNTOP >WVR_VALIDRECTS 以便使用您构建的两个矩形 (nccs_params->rgrc[1] 和 nccs_params->rgrc[2])通过 Windows，至少根据 MSDN 页面中非常简短的 dox WM_NCCALCSIZE 和 NCCALCSIZE_PARAMS。 Windows 10 可能对该返回值更加严格；我会尝试一下。

然而，即使我们假设我们可以说服 Windows 10 不要在 SetWindowPos() 中执行 BitBlt 操作，结果还是出现了一个新问题...

Windows 10（也可能是还有 Windows 8）在 XP/Vista/7 的旧传统骚扰之上添加了另一层客户区骚扰。

在 Windows 10 下，应用程序不会直接绘制到帧缓冲区，而是绘制到 Aero 窗口管理器 (DWM.exe) 合成的屏幕外缓冲区中。

事实证明，DWM 有时会决定通过在您的客户区域上绘制自己的内容来“帮助”您（有点像 BitBlt，但更反常，甚至进一步超出您的控制）。

因此，为了避免客户区干扰，我们仍然需要控制 WM_NCCALCSIZE，但我们还需要防止 DWM 干扰您的像素。

我正在与完全相同的问题作斗争，并创建了一个综述问题/答案，其中汇集了 10 年有关该主题的帖子，并提供了一些新的见解（太长，无法将内容粘贴到该问题中）。从 Windows Vista 开始，上述 BitBlt 不再是唯一的问题。享受：

如何平滑丑陋的抖动/调整窗口大小时闪烁/跳跃，尤其是拖动左/上边框（Win 7-10；bg、bitblt 和 DWM）？

Answer 4

对于某些控件，可以使用WM_PRINT消息使控件绘制到DC中。但这并不能真正解决您的主要问题，即您希望 Windows 在调整大小期间不绘制任何内容，而是让您完成所有操作。

答案是，只要有子窗口，你就无法做你想做的事。

我最终在自己的代码中解决这个问题的方法是切换到使用 无窗口控件。由于它们没有自己的窗口，因此它们总是与其父窗口同时绘制（并进入同一个 DC）。这允许我使用简单的双缓冲来完全消除闪烁。当我需要时，我什至可以通过不调用父级绘制例程中的绘制例程来简单地抑制子级的绘制。

这是我所知道的在调整大小操作期间完全消除闪烁和撕裂的唯一方法。

Answer 5

如果您能找到插入的地方，CWnd::LockWindowUpdates() 将阻止任何绘图发生，直到您解锁更新为止。

但请记住，这是一种黑客攻击，而且是一种相当丑陋的黑客攻击。调整大小时你的窗口看起来会很糟糕。如果您遇到的问题是在调整大小期间闪烁，那么最好的办法是诊断闪烁，而不是通过遮挡油漆来隐藏闪烁。

需要注意的一件事是在调整大小期间调用过于频繁的重绘命令。如果您的窗口控件正在调用 RedrawWindow()指定了RDW_UPDATENOW标志后，它将立即重新绘制。但是您可以删除该标志并指定 RDW_INVALIDATE 来代替，这会告诉控件使窗口无效而无需重新绘制。它会在闲置时重新绘制，使显示保持新鲜，而不会显得花哨。

Answer 6

有多种方法，但我发现唯一可以普遍使用的方法是双缓冲：绘制到屏幕外缓冲区，然后将整个缓冲区传输到屏幕。

Vista Aero 及更高版本中免费提供此功能，因此您的痛苦可能是短暂的。

我不知道 XP 下 Windows 和系统控件的通用双缓冲实现，但是，这里有一些需要探索的内容：

Keith Rule 的 CMemDC 用于双缓冲您用 GDI 自己绘制的任何内容
WS_EX_COMPOSITED 窗口样式（请参阅备注部分，以及stackoverflow上的内容）

Answer 7

只有一种方法可以有效诊断重画问题——远程调试。

购买第二台电脑。在其上安装 MSVSMON。添加构建后步骤或实用程序项目，将构建产品复制到远程 PC。

现在您应该能够在 WM_PAINT 处理程序、WM_SIZE 处理程序等中放置断点，并在执行大小和重绘时实际跟踪对话框代码。如果您从 MS 符号服务器下载符号，您将能够看到完整的调用堆栈。

一些放置得很好的断点 - 在您的 WM_PAINT、WM_ERAGEBKGND 处理程序中，您应该很清楚为什么您的窗口在 WM_SIZE 周期的早期被同步重绘。

系统中有很多窗口由父窗口和分层子控件组成 - 资源管理器窗口非常复杂，包含列表视图、树视图预览面板等。资源管理器在调整大小时不存在闪烁问题，因此很可能获得父窗口的无闪烁调整大小：-您需要做的是捕获重绘，找出导致它们的原因，然后确保消除原因。

Answer 8

似乎有效的方法：

1. 在父对话框上使用 WS_CLIPCHILDREN（可以在 WM_INITDIALOG 中设置）
2. 在 WM_SIZE 期间，循环遍历子控件，使用 DeferSetWindowPos() 移动和调整它们的大小。

在我使用 Aero 在 Windows 7 下进行的测试中，这非常接近完美。