@copilot your fix - making the toolbar permanently visible - is an interesting idea for a workaround.

Adding WS_VSCROLL did not achieve this. The scroll bar is still "dynamic" - appears and disappears when the content length changes.

Disregarding the above workaround. I'm very interested why resizing the the window causes the "content width value" to be updated and therefore the canvas redrawn with proper horizontal scaling. Can the "process" that happens when resizing the window be somehow recreated when showing/hiding the scroll bar?

An interesting side note - the exact same solvespace.exe has the problem on Windows 10 and windows 11 and does not have the problem on Windows 2000 and Windows XP. This means that the behaviour is somehow influenced by differences in the Win32 (GDI ?) implementations between these Windows versions. Can you find something based on this?

@copilot your fix - making the toolbar permanently visible - is an interesting idea for a workaround.

Adding WS_VSCROLL did not achieve this. The scroll bar is still "dynamic" - appears and disap...

You were right that WS_VSCROLL alone wasn't sufficient. The key missing piece was SIF_DISABLENOSCROLL.

When SetScrollInfo is called without SIF_DISABLENOSCROLL, Windows auto-hides the scrollbar (removing it from the client area, changing its width) whenever page >= range. This happens even with WS_VSCROLL set. On Windows 2000/XP, this change apparently triggered WM_SIZE, so ANGLE/GL would resize its surface. On Windows 10/11, it no longer does.

Fix in commit 53140cf: added SIF_DISABLENOSCROLL to the fMask in ConfigureScrollbar. Now when content fits the view, Windows disables (greys out) the scrollbar instead of hiding it — the client area width stays constant, ANGLE's swap chain stays in sync with the window, and click areas remain aligned with the rendered icons.

Combined with WS_VSCROLL ensuring the scrollbar space is reserved from creation, the client area width is now stable throughout the window's lifetime regardless of content length changes.

@copilot I pulled the version with SIF_DISABLENOSCROLL and tested it. The scroll bar is now permanent and therefore the workaround (that @phkahler initially suggested) is implemented and works. The problem can not be reproduced any more.

While the workaround works I want to get to the root of the problem.

I read your detailed thoughts on the WM_SIZE message being the reason that the content gets properly resized when changing the window size and is not when showing/hiding the scroll bar. In the past I actually debugged (on Windows 10) and WM_SIZE is not sent when the scroll bar visibility changes. I have not debugged on Windows XP but your theory that it does send WM_SIZE in this case is plausible.

Is there a way to "manually" send WM_SIZE when changing the scroll bar visibility? Or emulate what it does?

@copilot I pulled the version with SIF_DISABLENOSCROLL and tested it. The scroll bar is now permanent and therefore the workaround (that @phkahler initially suggested) is implement...

Yes, WM_SIZE can be synthesized manually. The pattern would be:

void SetScrollbarVisible(bool visible) override {
    bool wasVisible = scrollbarVisible;
    scrollbarVisible = visible;
    if(visible != wasVisible) {
        ShowScrollBar(hWindow, SB_VERT, visible ? TRUE : FALSE);
        // Synthesize WM_SIZE so ANGLE detects the client width change
        // and resizes its D3D swap chain before the next render.
        RECT rc;
        GetClientRect(hWindow, &rc);
        SendMessage(hWindow, WM_SIZE, SIZE_RESTORED,
                    MAKELPARAM(rc.right - rc.left, rc.bottom - rc.top));
    }
}

WM_SIZE in our handler just calls Invalidate(), which queues a WM_PAINT. During that paint, eglSwapBuffers is called — at that point ANGLE (D3D11 backend) detects the HWND size has changed and calls IDXGISwapChain::ResizeBuffers. The first post-resize frame may still be discarded/blank, so you'd likely see a brief one-frame stutter. The SIF_DISABLENOSCROLL approach avoids this entirely by making the client width invariant — no resize detection needed.

On Windows 2000/XP the scrollbar visibility change apparently triggered WM_SIZE automatically (perhaps as a side-effect of WM_NCCALCSIZE triggering a size notification differently in those older DWM/user32 versions), so ANGLE always had a chance to resize before the next render. On Windows 10/11 that automatic WM_SIZE was dropped.

The current SIF_DISABLENOSCROLL fix in 53140cf sidesteps the resize issue completely and is verified working. The synthesized WM_SIZE route is viable if a dynamically-hiding scrollbar is preferred, but at the cost of a potential single-frame glitch on each transition.