移动/调整窗口大小时闪烁

Question

我开发了一个显示 jpeg 图像的应用程序。它可以显示 4 个图像，在屏幕的每个象限中显示一个。它为此使用了 4 个窗口。窗口没有边框（框架）也没有标题栏。 加载新图像时，为新图像调整窗口大小，然后显示图像。

特别是当窗口变大时，经常会出现闪烁。在我看来，在显示新内容之前调整大小时似乎旧内容被移动了。

我查阅了很多资源并使用了所有技巧：

• 窗口只有CS_DBLCLKS 样式（没有CS_HREDRAW 或CS_VREDRAW）；

• 背景画笔为NULL；

• WM_ERASEBKGND 返回 1；

• WM_NCPAINT 返回 0；

• WM_NCCALCSIZE 告诉对齐到未移动的一侧（你能告诉它丢弃客户区吗？）；

• WM_WINDOWPOSCHANGING返回0；

• SetWindowPos 有标志SWP_NOCOPYBITS | SWP_DEFERERASE | SWP_NOREDRAW | SWP_NOSENDCHANGING。

不过，在调整窗口大小时会发生闪烁（或内容移动）。我想要的是：

• 将WindowPos 设置为新的大小和位置；

• InvalidateRect (hWnd, NULL, FALSE);

• UpdateWindow(hWnd);

在WM_PAINT之前没有任何绘画、背景擦除或内容移动。

WM_PAINT 会：

hDC= BeginPaint (hWnd, &ps);
hMemDC= CreateCompatibleDC (hDC);
hOldBitmap = SelectObject (hMemDC, hNewBitmap);
BitBlt (hDC,...,hMemDC,0,0,SRCCOPY);
SelectObject (hMemDC, hOldBitmap);
DeleteDC (hMemDC);
EndPaint (hWnd, &ps);

谁能告诉我我是否/在哪里犯了导致窗口旧内容被移动的错误？

硬件等：HP Elitebook Core7 64 位 Windows 7 和 NVIDIA Quadro K1000m 驱动程序 9.18.13.3265（更新至 341.44）。

---

更新（2017 年 7 月）

我也在另一台 Windows 计算机 (Windows 8/10) 上看到了程序的行为。它似乎不是 NVIDIA 显示驱动程序。

将平铺到屏幕中心的窗口（右下角 = w/2, h/2）调整到左上角或左上角 (0, 0) 时，该行为最为明显。

我可能在计算 WM_NCCALCSIZE 消息时遇到问题，告诉 Windows 不要做任何事情。任何人都可以为我的目的提供一个示例计算吗？另见How do I force windows NOT to redraw anything in my dialog when the user is resizing my dialog?

Answer 1

你有一个令人印象深刻的防闪烁技巧列表:-)

我不知道这是否重要（因为这取决于您的工具窗口是如何创建的，尤其是它们是否是共同父级的子窗口）： 尝试在工具窗口的父窗口中设置窗口样式WS_CLIPCHILDREN（如果有的话）。

如果未设置，父窗口将擦除其（整个）背景，然后将绘制消息转发到子窗口，这将导致闪烁。如果设置了WS_CLIPCHILDREN，则父窗口对子窗口占用的客户区不做任何事情。结果子窗口的区域没有被绘制两次，也没有闪烁的机会。

Answer 2

这是一个理论而不是一个答案：

默认情况下，在现代 Windows 中，您的窗口只是显卡上的纹理，桌面窗口管理器会将其映射到屏幕上的矩形。您似乎已经做了所有必要的事情来确保一举更新纹理。

但是当您调整窗口大小时，桌面合成器可能会立即更新其几何图形，从而导致（仍然未更改的）纹理出现在屏幕上的新位置。只有稍后，当您进行绘制时，纹理才会更新。

您可以通过暂时关闭桌面合成来测试这个理论。在 Windows 7 上，导航到“系统属性”，选择“高级”选项卡，在“性能”下选择“设置...”，在“视觉效果”选项卡上，取消选择“启用桌面合成”设置。然后尝试重现问题。如果它消失了，那么这支持（但不能绝对证明）我的理论。

（请记住重新启用合成，因为大多数用户大部分时间都是这样运行的。）

如果这个理论是正确的，那么目标似乎是在调整窗口大小后尽快上漆。如果时间窗口足够小，那么两者都可能在一个显示器刷新周期内发生，并且不会出现闪烁。

具有讽刺意味的是，您消除闪烁的努力在这里可能对您不利，因为您故意抑制了通常由 SetWindowPos 导致的无效和重绘，直到您在以后的步骤中手动执行。

调试提示：尝试在流程的关键点引入延迟（例如，Sleep(1000);），这样您就可以看到调整大小和重绘是否实际上作为两个不同的步骤在屏幕上呈现。

Answer 3

除了您的技巧列表之外。在使用左/上边缘调整窗口大小时，我的戴尔 XPS 笔记本电脑出现闪烁问题。你提到的所有技巧我都试过了。据我了解，窗口边框是在 GPU 中绘制的，窗口内容是在 GDI 子系统中准备的，然后传输到视频内存中进行窗口合成（Windows 8.1 中引入了 DWM）。我尝试完全删除 GDI 渲染（设置 WS_EX_NOREDIRECTIONBITMAP 样式），这会使窗口没有任何内容，然后直接使用 DXGI 子系统创建内容表面（使用 CreateSwapChainForComposition，关于如何执行此操作的示例很少）。但问题依然存在。在渲染窗口框架和调整/显示内容表面之间仍然存在延迟。

但是它可能会解决您的问题，因为您没有边框并且您不会注意到这种滞后。但是您将完全控制窗口重绘，并且它将在 GPU 端进行。

Answer 4

你确实有一套不错的技巧。

首先，我可以建议一些现有技巧的变体，尤其是在 XP/Vista/7 上可能会有所帮助，其次，我想提一下您在 Win8/10 上看到的持续闪烁可能来自哪里，以及一些可以减少的技巧那个。

首先，尽管在其他 OP 帖子中提出了相反的建议，但您可能会发现，如果您设置之前避免的 CS_HREDRAW|CS_VREDRAW 窗口样式，它实际上消除了在内部 SetWindowPos 窗口中完成的 BitBlt在调整窗口大小时会发生（但是——这是令人困惑的部分——在 Windows 8/10 上，您仍然会看到来自其他来源的闪烁...更多内容见下文）。

如果你不想包含CS_HREDRAW|CS_VREDRAW，你也可以拦截WM_WINDOWPOSCHANGING（首先将它传递给DefWindowProc）并设置WINDOWPOS.flags |= SWP_NOCOPYBITS，这会禁用@987654331内部调用中的BitBlt @Windows 在调整窗口大小时所做的。

或者，您可以添加到您的 WM_NCCALCSIZE 技巧，方法是让它返回一组值，这些值将告诉 Windows 仅在其自身顶部增加 1 个像素，这样即使 BitBlt 确实发生了，它也不会'不要做任何明显的事情：

case WM_NCCALCSIZE:
{
    RECT ocr; // old client rect
    if (wParam)
    {
        NCCALCSIZE_PARAMS *np = (NCCALCSIZE_PARAMS *)lParam;
        // np->rgrc[0] is new window rect
        // np->rgrc[1] is old window rect
        // np->rgrc[2] is old client rect
        ocr = np->rgrc[2];
    }
    else
    {
        RECT *r = (RECT *)lParam;
        // *r is window rect
    }

    // first give Windoze a crack at it
    lRet = DefWindowProc(hWnd, uMsg, wParam, lParam);

    if (wParam)
    {
        NCCALCSIZE_PARAMS *np = (NCCALCSIZE_PARAMS *)lParam;

        // np->rgrc[0] is new client rect computed
        // np->rgrc[1] is going to be dst blit rect
        // np->rgrc[2] is going to be src blit rect
        // 
        ncr = np->rgrc[0];
        RECT &dst = np->rgrc[1];
        RECT &src = np->rgrc[2];

        // FYI DefWindowProc gives us new client rect that
        // - in y
        //   - shares bottom edge if user dragging top border
        //   - shares top edge if user dragging bottom border
        // - in x
        //   - shares left edge if user dragging right border
        //   - shares right edge if user dragging left border
        //
        src = ocr;
        dst = ncr; 

        // - so src and dst may have different size
        // - ms dox are totally unclear about what this means
        // https://docs.microsoft.com/en-us/windows/desktop/
        //         winmsg/wm-nccalcsize
        // https://docs.microsoft.com/en-us/windows/desktop/
        //         api/winuser/ns-winuser-tagnccalcsize_params
        // - they just say "src is clipped by dst"
        // - they don't say how src and dst align for blt
        // - resolve ambiguity

        // essentially disable BitBlt by making src/dst same
        // make it 1 px to avoid waste in case Windoze still does it

        dst.right  = dst.left + 1;
        dst.bottom = dst.top  + 1;

        src.right  = dst.left + 1;
        src.bottom = dst.top  + 1;

        lRet = WVR_VALIDRECTS;
    }
    else // wParam == 0: Windoze wants us to map a single rect w->c
    {
        RECT *r = (RECT *)lParam;
        // *r is client rect
    }

    return lRet;

所以这一切都很好，但为什么 Windows 8/10 看起来如此糟糕？

Windows 8/10 Aero 下的应用程序不会直接绘制到屏幕上，而是绘制到屏幕外缓冲区，然后由邪恶的 DWM.exe 窗口管理器合成。 DWM 实际上在现有的旧版 XP/Vista/7 BitBlt 行为之上添加了另一层 BitBlt 类型的行为。

而且 DWM blit 行为更加疯狂，因为它们不仅复制客户区，而且实际上复制旧客户区边缘的像素以创建新客户区。不幸的是，让 DWM 不做它的 blit 比仅仅传递一些额外的标志要困难得多。

我没有 100% 的解决方案，但我希望以上信息会有所帮助，请参阅此问答，了解可用于减少应用程序发生 DWM 层 blit 的机会的计时技巧：

How to smooth ugly jitter/flicker/jumping when resizing windows, especially dragging left/top border (Win 7-10; bg, bitblt and DWM)?