-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DXGI warning with DX11 backend about DXGI_SWAP_EFFECT_DISCARD
#7607
Comments
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. |
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? |
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 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 |
Indeed yours look the same. |
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: (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) |
FYI i have asked about this at https://x.com/ocornut/status/1795060349084823686 |
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). |
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. |
If that's what makes a difference then I believe the issue goes way deeper actually (NIS isn't supposed to affect single windows, and even if it did with the default value that can be seen in the screenshot it shouldn't be doing practically anything anyway). It's not FLIP_* that drops dpi-scaling, but DXGI_HARDWARE_COMPOSITION_SUPPORT_FLAG_WINDOWED. |
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:
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).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'sCreateDeviceD3D
, if testing there) like so resolves the warning (unsurprisingly):Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
Uncomment this line in
examples/example_win32_directx11/main.cpp
: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.
The text was updated successfully, but these errors were encountered: