DXGI warning with DX11 backend about DXGI_SWAP_EFFECT_DISCARD

[seanmiddleditch]

Version/Branch of Dear ImGui:

Version 1.90.6 WIP, Branch: docking (commit e391fe2)

Back-ends:

imgui_impl_win32.cpp + imgui_impl_dx11.cpp

Compiler, OS:

Windows 11 + MSVC 17.10.0 Preview 7.0

Full config/build information:

Dear ImGui 1.90.6 (19060)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: _WIN32
define: _WIN64
define: _MSC_VER=1940
define: _MSVC_LANG=201402
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_win32
io.BackendRendererName: imgui_impl_dx11
io.ConfigFlags: 0x00000441
 NavEnableKeyboard
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoAutoMerge
io.ConfigViewportsNoDefaultParent
io.ConfigDockingTransparentPayload
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigWindowsMoveFromTitleBarOnly
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00001C0E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 HasMouseHoveredViewport
 RendererHasVtxOffset
 RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1264.00,761.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Details:

My Issue/Question:

Previously noted in #2970 (comment) by another user.

Using the DX11 backend using a device with the D3D11_CREATE_DEVICE_DEBUG creation flag set results in runtime warnings (only tested on docking branch). I believe that this is another consequence of needing a resolution to handling SDK versions as noted in #2970 (comment).

DXGI WARNING: IDXGIFactory::CreateSwapChain: Blt-model swap effects (DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_SEQUENTIAL) are legacy swap effects that are predominantly superceded by their flip-model counterparts (DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL and DXGI_SWAP_EFFECT_FLIP_DISCARD). Please consider updating your application to leverage flip-model swap effects to benefit from modern presentation enhancements. More information is available at http://aka.ms/dxgiflipmodel. [ MISCELLANEOUS WARNING #294: ]

This is of course super low-priority, but it is annoying when trying to verify that the app is clean of any runtime warnings/errors (without customizing the backend).

I verifyed that changing ImGui_ImplDX11_CreateWindow (and the example app's CreateDeviceD3D, if testing there) like so resolves the warning (unsurprisingly):

sd.BufferCount = 2; // was 1
sd.SwapEffect = DXGI_SWAP_EFFECT_FLIP_DISCARD; // was DXGI_SWAP_EFFECT_DISCARD

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

Uncomment this line in examples/example_win32_directx11/main.cpp:

//createDeviceFlags |= D3D11_CREATE_DEVICE_DEBUG;

Debug in Visual Studio and observe the DXGI warning in the IDE's Output window. More show up if dragging imgui windows out into their own viewports.

[ocornut]

Based on Windows SDK version we could use newer swap effects, but analoguous to how we expose options in eg vulkan backends perhaps it should be exposed to the backend user which settings they want to use for the swapchain.

[ocornut]

I tried with _FLIP_DISCARD and _FLIP_SEQUENTIAL and I noticed that on non-DPI aware app my rendering looks less readable. It's like the upscaling for non-DPI aware apps is different with those settings. Strangely enough when I move the window by dragging the win32 title bar, during the move the visual looks correct. I don't really know what to make of that. Do you have this effect too?

[seanmiddleditch]

I haven't noticed anything, but frankly I'm not even paying attention to whether I'm running things in DPI-aware mode or not.

Here's the example_win32_directx11 app right out of the imgui repo:

And with _FLIP_DISCARD (changed in both main.cpp and in imgui_impl_dx11.cpp):

And then after I drag the window out of the main viewport:

Assuming that is non-DPI-aware (based on this function being commented out in main : //ImGui_ImplWin32_EnableDpiAwareness();), well... looks indistinguishable to me?

[ocornut]

Indeed yours look the same.
On mine it looks different WHILE DRAGGING then goes back to shit after dragging. Seems like a bizarre bug or odd drivers or windows thing, will try to investigate another time.

[ocornut]

• I updated to latest NVIDIA drivers and still have same problem.
• The DX12 example seems always DPI aware (I don't even know why?) so doesn't exhibit the issue.
• I wanted to try if using more recent swap chain version and options in DX11 (e.g. DXGI_SWAP_CHAIN_DESC1, IDXGISwapChain1) solved the problem but it didn't.
• To clarify, this is on a Windows 10 desktop. Nvidia RTX 2080 TI

I guess when using FLIP_ mode the non-DPI aware scale is handled by someone/something different. I wouldn't mind in theory, but on my LCD screen it really feels it looks less readable, and the fact that it looks different while dragging the Win32 window seems very odd to me. Uploading a video in case someones knows the reason:
https://github.com/ocornut/imgui/assets/8225057/2885c0a0-344c-4080-960e-2496cd97a5ad
(you can see the difference in the recording, but on my screen it feels noticeably less readable)

(I understand that switching to DPI aware example is going to be the most desirable step anyhow, but until we've paved the right steps toward that direction, it's not a trivial switch)

[ocornut]

FYI i have asked about this at https://x.com/ocornut/status/1795060349084823686

[ocornut]

Culprit is this NVIDIA option which default to Off:

[seanmiddleditch]

Ah, alright. When I took those screenshots I was on an AMD (RX 6700 XT) system. I don't recall seeing anything funky on my NVIDIA+Arc laptop (though maybe my app was only running on the Intel Arc and not the NVIDIA; I'll have to look into that).

[ocornut]

You have nothing to investigate, I understood the issue now. It puts a little extra pressure at us making examples/ app DPI-aware if we switch to using FLIP_DISCARD by default. Will do both eventually.