14

I am drawing an animation using double-buffered GDI on a window, on a system where DWM composition is enabled, and seeing clearly visible tearing onscreen. Is there a way to prevent this?

Details

The animation takes the same image, and moves it right to left over the screen; the number of pixels across is determined by the difference between the current time and the time the animation started and the time to end, to get a fraction complete which is applied to the whole window width, using timeGetTime with a 1ms resolution. The animation draws in a loop without processing application messages; it calls the (VCL library) method Repaint which internally invalidates and then calls UpdateWindow for the window in question, directly calling into the message procedure with WM_PAINT. The VCL implementation of the paint handler uses BeginBufferedPaint. Painting is itself double-buffered.

The aim of this is to have as high a frame-rate as possible to get a smooth animation across the screen. (The drawing uses double-buffering to remove flickering and to ensure a whole image or frame is onscreen at any one time. It invalidates and updates directly by calling into the message procedure, without doing other message processing. Painting is implemented using modern techniques (eg BeginBufferedPaint) for Aero composition.) Within this, painting is done in a couple of BitBlt calls (one for the left side of the animation, ie what's moving offscreen, and one for the right side of the animation, ie what's moving onscreen.)

When watching the animation, there is clearly visible tearing. This occurs on Windows Vista, 7 and 8.1 on multiple systems with different graphics cards.

My approach to handle this has been to reduce the rate at which it is drawing, or to try to wait for VSync before painting again. This might be the wrong approach, so the answer to this question might be "Do something else completely: X". If so, great :)

(What I'd really like is a way to ask the DWM to compose / use only fully-painted frames for this specific window.)

I've tried the following approaches, none of which remove all visible tearing. Therefore the question is, Is it possible to avoid tearing when using DWM composition, and if so how?

Approaches tried:

  • Getting the monitor refresh rate via GetDeviceCaps(Application.MainForm.Handle, VREFRESH); sleeping for 1 / refresh rate milliseconds. Slightly improved over painting as fast as possible, but may be wishful thinking. Perceptually slightly less smooth animation rate. (Tweaks: normal Sleep and a high-resolution spin-wait using timeGetTime.)

  • Using DwmSetPresentParameters to try to limit updating to the same rate at which the code draws. (Variations: lots of buffers (cBuffer = 8) (no visible effect); specifying a source rate of monitor refresh rate / 1 and sleeping using the above code (the same as just trying the sleeping approach); specifying a refresh per frame of 1, 10, etc (no visible effect); changing the source frame coverage (no visible effect.)

  • Using DwmGetCompositionTimingInfo in a variety of ways:

      • While cFramesPending > 0, spin;
      • Get cFrame (frame composed) and spin while this number doesn't change;
      • Get cFrameDisplayed and spin while this doesn't change;
      • Calculating a time to sleep to by adding qpcVBlank + qpcRefreshPeriod, and then while QueryPerformanceCounter returns a time less than this, spin

  • All these approaches have also been varied by painting, then spinning/sleeping before painting again; or the reverse: sleeping and then painting.

Few seem to have any visible effect and what effect there is is hard to qualify and may just be a result of a lower frame rate. None prevent tearing, ie none make the DWM compose the window with a "whole" copy of the contents of the window's DC.

Advice appreciated :)

David
  • 13,360
  • 7
  • 66
  • 130
  • 1
    GDI is old and crusty and not up to smooth animation. Maybe try Direct2D? – Jonathan Potter Oct 02 '14 at 19:06
  • 1
    @JonathanPotter Good point. One of the constraints I'm under is not to use DX of any sort - one reason is the number of platforms, and lack of requirements, the final code needs to run on. (Not all are modern Windows.) Perhaps helper DX code only when Aero exists...? However, the it would have to seamlessly switch to and from GDI/DX with no visual glitches, as it turns on/off the animation. Is that possible? – David Oct 02 '14 at 19:18
  • Maybe you could write a drawing helper class that uses DX if available and falls back to GDI otherwise. It would be pretty rare to find a system that didn't support Direct3D though even if not D2D. – Jonathan Potter Oct 02 '14 at 20:54
  • 5
    Direct2D is fairly slow. You can prevent tearing, in exchange for **slower** animations using Direct2D. In essence, Direct2D is merely a support/utility library built on top of Direct3D, that maps 2D rendering calls to D3D rendering primitives. Certain operations are extremely slow (rounded rectangles, dashed lines, etc.), roughly an order of magnitude slower than GDI rendering. – IInspectable Oct 04 '14 at 16:36
  • What about OpenGL? For simple 2D animation might be a good choice and it is rather simple (compared to DX). – Eldarien Jun 24 '15 at 11:01
  • @Eldarien Good idea. The problem might be setup and teardown: would there be any graphic glitches when init-ing and closing GL? – David Jun 24 '15 at 16:00
  • If all your drawing in a window will be done with openGL than you should not have any problems. But if you want to draw GL objects over existing graphics done with GDI than there may be some issues, but they can be fixed. For example look at this post: https://www.opengl.org/discussion_boards/showthread.php/175512-RE-mixing-GDI-with-OpenGL – Eldarien Jun 26 '15 at 09:39
  • 2
    @Eldarien: How is using OpenGL on Windows any more appropriate than using DirectX? What sort of problems does using OpenGL solve over using DirectX? How is OpenGL better integrated into DWM? How is it easier to debug? How is the recommendation to use OpenGL addressing the question? – IInspectable Aug 22 '15 at 14:13
  • 1
    disable WM_ERASEBKGND, by subclassing, supperclassing , or other way. you may also set NULL brush to the classname – milevyo Oct 24 '15 at 05:24
  • @milevyo That would reduce flicker, but how or why would it reduce tearing? – David Oct 27 '15 at 12:22
  • 2
    I believe you can sync to the video frame rate in a nice way by calling DwmFlush(). I'm not sure why nobody else has suggested this. – Andrew Bainbridge Aug 10 '18 at 16:15

1 Answers1

3

Since you're using BitBlt, make sure your DIBs are 4-bytes / pixel. With 3 bytes / pixel, GDI is horribly slow while DWM is running, that could be the source of your tearing. Another BitBlt issue I've run into, if your DIB is somewhat larger, than the BitBlt call make take an unexpectedly long time. If you split up one call into smaller calls than only draw a portion of the data, it might help. Both of these items helped me for my case, only because BitBlt itself was running too slow, thus leading to video artifacts.

Chris O
  • 5,017
  • 3
  • 35
  • 42
  • 1
    Just in case adding: not to forget to update only dirty rect (GetUpdateRect) instead of whole window... – Jurlie Dec 22 '16 at 23:33