使用 GDI+ 和 C++ 减少闪烁

Reduce flicker with GDI+ and C++

提问by djeidot

I'm using GDI+ in a C++/MFC application and I just can't seem to avoid flickering whenever the window is resized.

我在 C++/MFC 应用程序中使用 GDI+，但每当调整窗口大小时，我似乎都无法避免闪烁。

I have already tried these steps:

我已经尝试过以下步骤：

• returned TRUE on OnEraseBkGnd();
• returned NULL on OnCtlColor();
• used double buffering according to this code:

• 返回 TRUE OnEraseBkGnd()；
• 返回 NULL OnCtlColor()；
• 根据此代码使用双缓冲：

void vwView::OnDraw(CDC* pDC) 
{
   CRect rcClient;
   GetClientRect(rcClient);

   Bitmap bmp(rcClient.Width(), rcClient.Height());
   Graphics graphics(&bmp);

   graphics.DrawImage(m_image, rcClient.left, rcClient.top);

   Graphics grph(pDC->m_hDC);
   grph.DrawImage(&bmp, 0, 0);
}

Am I doing something wrong? Or is there another way to achieve this?

难道我做错了什么？还是有另一种方法来实现这一目标？

回答by Shog9

To completely avoid flicker, you would need to complete alldrawing in the interval between screen updates. Windows does not provide any easy means of accomplishing this for normal window painting (Vista provides composite drawing via the DWM, but this cannot be relied on even on systems running Vista). Therefore, the best you can do to minimize flicker is to draw everything as quickly as possible (reducetearing by increasing your chances of completing all drawing within a refresh cycle), and avoid overdraw (drawing part of the screen and then drawing something else over the top: risks presenting user with a partially-drawn screen).

为了完全避免闪烁，您需要在屏幕更新之间的时间间隔内完成所有绘图。Windows 没有为普通窗口绘制提供任何简单的方法来完成此操作（Vista 通过DWM提供复合绘制，但即使在运行 Vista 的系统上也不能依赖于此）。因此，尽量减少闪烁的最佳方法是尽快绘制所有内容（通过增加在刷新周期内完成所有绘制的机会来减少撕裂），并避免过度绘制（绘制屏幕的一部分，然后再绘制其他内容）顶部：向用户展示部分绘制的屏幕的风险）。

Let's discuss the techniques presented here so far:

让我们讨论目前为止介绍的技术：

• Do-nothing OnEraseBkgnd(): helps to avoid over-draw by preventing the invalidated area of the window from being filled with the window's background color. Useful when you will be drawing the entire area again during WM_PAINThandling anyway, as in the case of double-buffered drawing... but see Notes on avoiding overdraw by preventing drawing after your WM_PAINTmethod.

• Returning NULL for OnCtlColor(): this shouldn't actually do anything... unless you have child controls on your form. In that case, see Notes on avoiding overdraw by preventing drawing after your WM_PAINTmethodinstead.

• Double buffered drawing: helps to avoid tearing (and potentially overdraw as well), by reducing the actual on-screen drawing to a single BitBLT. May hurt the time needed for drawing though: hardware acceleration cannot be used (although with GDI+, the chances of any hardware-assisted drawing being used are quite slim), an off-screen bitmap must be created and filled for each redraw, and the entire window must be repainted for each redraw. See Notes on efficient double-buffering.

• Using GDI calls rather than GDI+ for the BitBlt: This is often a good idea - Graphics::DrawImage()can be very slow. I've even found the normal GDI BitBlt()call to be faster on some systems. Play around with this, but only after trying a few other suggestions first.

• Avoiding window class styles that force a full redraw on each resize (CS_VREDRAW, CS_HREDRAW): This will help, but only if you don't needto redraw the entire window when size changes.

• Do-nothing OnEraseBkgnd()：通过防止窗口的无效区域被窗口的背景颜色填充来帮助避免过度绘制。无论如何，当您在WM_PAINT处理期间再次绘制整个区域时很有用，就像在双缓冲绘制的情况下一样...但请参阅通过在WM_PAINT方法之后防止绘制来避免过度绘制的注意事项。

• 为OnCtlColor()返回 NULL：这实际上不应该做任何事情......除非您的表单上有子控件。在这种情况下，请参阅有关通过在WM_PAINT方法之后防止绘制来避免过度绘制的说明。

• 双缓冲绘图：通过将实际的屏幕绘图减少到单个BitBLT来帮助避免撕裂（以及潜在的过度绘制）。可能会缩短绘制所需的时间：无法使用硬件加速（尽管使用 GDI+，使用任何硬件辅助绘制的机会非常渺茫），必须为每次重绘创建和填充离屏位图，并且每次重绘都必须重绘整个窗口。请参阅关于高效双缓冲的注释。

• 对 BitBlt 使用 GDI 调用而不是 GDI+：这通常是一个好主意 -Graphics::DrawImage()可能非常慢。我什至发现BitBlt()在某些系统上正常的 GDI调用速度更快。试试这个，但前提是先尝试其他一些建议。

• 避免窗口类样式，迫使每个调整大小（一个完整的重绘CS_VREDRAW，CS_HREDRAW）：这将帮助，但是只有当你没有需要重绘整个窗口大小改变时。

Notes on avoiding overdraw by preventing drawing prior to your WM_PAINTmethod

通过在WM_PAINT方法之前阻止绘制来避免过度绘制的注意事项

When all or a portion of a window is invalidated, it will be erased and repainted. As already noted, you can skip erasing if you plan to repaint the entire invalid area. However, if you are working with a child window, then you must ensure that parent window(s) are not also erasing your area of the screen. The WS_CLIPCHILDRENstyle should be set on all parent windows - this will prevent the areas occupied by child windows (including your view) from being drawn on.

当窗口的全部或部分无效时，它将被擦除并重新绘制。如前所述，如果您打算重新绘制整个无效区域，则可以跳过擦除。但是，如果您正在使用子窗口，那么您必须确保父窗口不会同时擦除您的屏幕区域。在WS_CLIPCHILDREN风格应该在所有父窗口中设置-这将防止区域被抽上所占的子窗口（包括您的视图）。

Notes on avoiding overdraw by preventing drawing after your WM_PAINTmethod

通过在WM_PAINT方法之后防止绘制来避免过度绘制的注意事项

If you have anychild controls hosted on your form, you will want to use the WS_CLIPCHILDRENstyle to avoid drawing over them (and subsequently being over drawn by them. Be aware, this will impact the speed of the BitBlt routine somewhat.

如果您的窗体上有任何子控件，您将希望使用WS_CLIPCHILDREN样式来避免绘制它们（随后被它们过度绘制。请注意，这会在一定程度上影响 BitBlt 例程的速度。

Notes on efficient double-buffering

高效双缓冲的注意事项

Right now, you're creating a new back-buffer image each time the view draws itself. For larger windows, this can represent a significant amount of memory being allocated and released, and willresult in significant performance problems. I recommend keeping a dynamically-allocated bitmap in your view object, re-allocating it as needed to match the size of your view.

现在，每次视图绘制自己时，您都在创建一个新的后台缓冲图像。对于较大的窗口，这可能表示分配和释放大量内存，并将导致严重的性能问题。我建议在视图对象中保留一个动态分配的位图，根据需要重新分配它以匹配视图的大小。

Note that while the window is being resized, this will result in just as many allocations as the present system, since each new size will require a new back buffer bitmap to be allocated to match it - you can ease the pain somewhat by rounding dimensions up to the next largest multiple of 4, 8, 16, etc., allowing you to avoid re-allocated on each tiny change in size.

请注意，在调整窗口大小时，这将导致与当前系统一样多的分配，因为每个新大小都需要分配一个新的后台缓冲区位图来匹配它 - 您可以通过向上取整尺寸来减轻痛苦到 4、8、16 等的下一个最大倍数，让您避免在每次微小的大小变化时重新分配。

Note that, if the size of the window hasn't changed since the last time you rendered into the back buffer, you don't need to re-render it when the window is invalidated - just Blt out the already-rendered image onto the screen.

请注意，如果窗口的大小自上次渲染到后台缓冲区后没有改变，则当窗口无效时不需要重新渲染它 - 只需将已经渲染的图像 Blt 输出到屏幕。

Also, allocate a bitmap that matches the bit depth of the screen. The constructor for Bitmapyou're currently using will default to 32bpp, ARGB-layout; if this doesn't match the screen, then it will have to be converted. Consider using the GDI method CreateCompatibleBitmap()to get a matching bitmap.

此外，分配与屏幕位深度匹配的位图。Bitmap您当前使用的构造函数将默认为 32bpp，ARGB 布局；如果这与屏幕不匹配，则必须对其进行转换。考虑使用 GDI 方法CreateCompatibleBitmap()来获取匹配的位图。

Finally... I assume your example code is just that, an illustrative snippet. But, if you are actually doing nothing beyond rendering an existing image onto the screen, then you don't really need to maintain a back buffer at all - just Blt directly from the image (and convert the format of the image ahead of time to match the screen).

最后......我假设你的示例代码就是一个说明性的片段。但是，如果您实际上除了将现有图像渲染到屏幕上之外什么都不做，那么您根本不需要维护后台缓冲区 - 只需直接从图像中 Blt（并提前将图像格式转换为匹配屏幕）。

回答by Mark Ransom

You might try using old-fashioned GDI rather than GDI+ to write to the DC, especially since you're already buffering the image. Use Bitmap::LockBits to access the raw bitmap data, create a BITMAPINFO structure, and use SetDIBitsToDevice to display the bitmap.

您可以尝试使用老式 GDI 而不是 GDI+ 来写入 DC，特别是因为您已经在缓冲图像。使用 Bitmap::LockBits 访问原始位图数据，创建一个 BITMAPIINFO 结构，并使用 SetDIBitsToDevice 来显示位图。

回答by rogerdpack

You may get some traction through using Direct3Dto "tell" you when vsync's occur, et al, so you can BitBlt/update at a good time. See GDI vsync to avoid tearing(though getting things down to a single small BitBlt may be "good enough" for some cases).

您可能会通过使用Direct3D来“告诉”您何时发生 vsync，从而获得一些牵引力，因此您可以在合适的时间进行 BitBlt/更新。请参阅GDI vsync 以避免撕裂（尽管在某些情况下将事情归结为单个小 BitBlt 可能“足够好”）。

Also note that it appears that GDI BitBlt isn't synchronized with screen vsync. See Faster than BitBlt.

另请注意，GDI BitBlt 似乎与屏幕垂直同步不同步。请参阅比 BitBlt 更快。

Also note that using CAPTUREBLT (which allows you to capture transparent windows) causes the mouse to flicker (if aero is not in use) if used.

另请注意，使用 CAPTUREBLT（允许您捕获透明窗口）会导致鼠标闪烁（如果未使用 aero）（如果使用）。

回答by Frederik Slijkerman

Make sure that the window class for the window does not include the CS_VREDRAW and CS_HREDRAW flags in its style.

确保窗口的窗口类在其样式中不包括 CS_VREDRAW 和 CS_HREDRAW 标志。

See http://msdn.microsoft.com/en-us/library/ms633574(VS.85).aspx

请参阅http://msdn.microsoft.com/en-us/library/ms633574(VS.85).aspx

回答by Liam

This link contains some useful info: http://www.catch22.net/tuts/flicker-free-drawing

此链接包含一些有用的信息：http: //www.catch22.net/tuts/flicker-free-drawing

(I know this is a very late addition to the thread, but this is for anyone (like me) who found it when looking to reduce flicker in my Win32 app...)

（我知道这是该线程的一个很晚的补充，但这是为任何人（如我）在希望减少我的 Win32 应用程序中的闪烁时发现它...）

回答by Chris Becke

Are there child windows on the form? The Window manager starts by getting the parent window to erase its background by sending a WM_ERASEBKGND message, THEN it sends a wM_PAINT message - presumably this maps to your wx::OnDraw method. Then it iterates over each child control and gets those to paint themselves.

表单上有子窗口吗？窗口管理器首先通过发送 WM_ERASEBKGND 消息让父窗口擦除其背景，然后发送 wM_PAINT 消息 - 大概这映射到您的 wx::OnDraw 方法。然后它遍历每个子控件并让它们自己绘制。

If this is your scenario... using Vistas new aero look would solve your problem as the aero desktop window manager does window compositing automatically. With the older window manager its a pita.

如果这是您的情况...使用 Vistas 新的航空外观将解决您的问题，因为航空桌面窗口管理器会自动进行窗口合成。使用较旧的窗口管理器它是一个皮塔饼。