Smooth window resizing in Windows (using Direct2D 1.1)?

Question

It annoys me that the resizing of windows in Windows is not as "smooth" as it I'd like it to be (this is the case with Windows programs in general, not just my own. Visual Studio is a good example). It makes the OS and its programs feel "flimsy" and "cheap" (yes, I care about how programs and user interfaces feel, in the same way I care about the sound and feel of closing a car door. It's a reflection of build quality), which in my view affects the overall UX and ultimately the perception of the brand.

The redrawing of window contents simply does not keep up with mouse movement during resize. Whenever I resize a window, there is a "stuttering" / "flickering" effect, seemingly due to the previous-size-contents of the window being redrawn in the new, resized window frame before the new, resized contents are drawn.

I am building a Win32 application (x64) that uses Direct2D 1.1 to draw its UI, and given the speed of Direct2D, i think it should be unnecessary to suffer such artifacts in an OS in 2014. I am on Windows 8.1 myself, but targeting Windows 7 and up with this application.

The "previous size" effect is especially discernible when maximizing a small window (since the difference in window size is sufficiently great to easily contrast the image of the old content as it flashes briefly in the upper left corner of the larger window with the new content subsequently being painted over it).

This is what appears to be going on:

(Let's say there's a fully rendered window on screen, size 500 x 500 pixels).
I maximize the window:
The window frame is maximized
The old 500 x 500 content is drawn in the new frame, before..
..the maximized window is repainted with properly sized content.

I'm wondering if there's any way to mitigate this (i.e. get rid of step 4) - via intercepting a Windows Message, for example - and avoid the window being repainted at the new size with the old content before the final re-rendering of the new content happens. It's like Windows does the window redrawing itself, using whatever graphics it already has available, BEFORE it bothers to ask me to provide updated content with a WM_PAINT message or similar.

Can it be done?

Edit: It seems that WM_WINDOWPOSCHANGING / WM_SIZING provides "early access" to the new size data, but I still haven't managed to suppress the painting of the old content.

My WndProc looks like this:

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_ERASEBKGND:
        return 1;
    case WM_PAINT:
        PAINTSTRUCT ps;
        BeginPaint(hWnd, &ps);
        D2DRender();
        EndPaint(hWnd, &ps);
        return 0;
    case WM_SIZE:
        if (DeviceContext && wParam != SIZE_MINIMIZED)
        {
            D2DResizeTargetBitmap();
            D2DRender();
        }
        return 0;
    case WM_DISPLAYCHANGE:
        D2DRender();
        return 0;
    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;
    }
    return DefWindowProc(hWnd, message, wParam, lParam);
}

The window does not have CS_HREDRAW or CS_VREDRAW set. The swapchain is double buffered and the Present call is made with SyncInterval = 0.

I am aware that recreating the swapchain buffers every time the window size changes does create some overhead compared to plain redrawing on a static window surface. However, the "stuttering" is not caused by that, as it happens even when buffer resizing is disabled and existing window contents are simply scaled during window resizing (although that does make it keep up better with mouse movement).

The problem is that in Windows painting messages are asynchronous - by the time you start handling a repaint the window could have already changed size again. You can minimize the effects with a lot of effort but you can never completely overcome it. — Jonathan Potter
Are we talking removing window borders and manually implementing drag/resize detection on the client area, determining new window size myself, resizing swapchain, repainting and THEN manually resizing the window before processing the next (current) mouse position? — d7samurai
Those are the sort of lengths you'd need to go to I suspect. — Jonathan Potter
@dialer: I understand the responsiveness concern, but I'm tossing graphics around at 60 FPS (which is the screen refresh rate anyway) in full screen windows, so I can't understand why the same redraw speed couldn't be used to update the window contents at 60 FPS during resizing, too.. — d7samurai
@dialer: Sure. I suspect this could be some kind of architectural relic from earlier OS versions, originally designed for slower processors and before Direct2D / GPU acceleration.. But this is 2014 and I want my applications to feel like a Mercedes, not a 70s Skoda :) — d7samurai

Unknown Unknown · Accepted Answer · 2014-04-11T15:28:14

What if you have a borderless childwindow (the type that only renders inside the parent) at a fixed size (same as fullscreen resolution), you should get a lot smoother results because there is no memory reallocation (which i think is what causes the jitterieness).

If it's still not perfect, look into both WM_SIZE and WM_SIZING and check if you can do some magic with them. For instance, on WM_SIZING you could return true telling Windows you handled the message (leaving the window as is) and you re-render your UI to a buffer with the size provided by WM_SIZING and when that is done, you send your own WM_SIZING but with a manipulated unused bit in WPARAM (along with its previous content) that tells you you have a pre-rendered buffer for this that you can just blit out. From the WM_SIZING documentation on msdn it looks like WPARAM should have a couple of bits at your disposal.

Hope this helps.

Smooth window resizing in Windows (using Direct2D 1.1)?

6 Answers