Win32 borderless windows comment to examine

[icculus]

SDL/src/video/windows/SDL_windowswindow.c

Lines 86 to 94 in bc5677d

	/* SDL 2.1:
	This behavior more closely matches other platform where the window is borderless
	but still interacts with the window manager (e.g. task bar shows above it, it can
	be resized to fit within usable desktop area, etc.) so this should be the behavior
	for a future SDL release.
	If you want a borderless window the size of the desktop that looks like a fullscreen
	window, then you should use the SDL_WINDOW_FULLSCREEN_DESKTOP flag.
	*/

I didn't look at this more closely, but something to consider for SDL3.

[ocornut]

Hello,

We have recently implemented an SDL3 backend for Dear ImGui.
(Ref: https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_sdl3.h + https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_sdl3.cpp)

This exact fix b4ebb3b is causing an issue with our integration of Multi-viewports which is an optional but highly-loved feature where users can drag Dear ImGui windows outside of the main window created by the user app, and our backend creates/destroy windows and render contexts to make the transition as smooth as possible.

With this change, every time a new window is created or is destroyed, Windows plays a very short "animation", which breaks the effect of simply dragging a window out and back-in. (I assume those animation are technically possible to disable in Windows settings, but that's outside the point of this issue).

I am assuming a side effect of this "interact better with window manager" is that Windows enable those animations. I don't know if there are other ways to disable them than set STYLE_BORDERLESS.

From the POV of that feature, the animation is highly problematic. However, I am aware that Dear ImGui multi-viewport integration is a rather advanced feature which tend to requires of libraries like SDL (or e.g GLFW) an amount control which may be difficult to burden you with. We could consider manually poking into win32's style attributes directly from our backend but it would relatively brittle as the styles computed from GetWindowStyle() in SDL_windowswindow.c are reapplied from a few others setters.

Repro:

• Pull latest docking branch in Dear ImGui repro.
• Open examples/imgui_examples.sln and build example_sdl3_opengl3, run the application.
• When application opens, click on a Dear ImGui window (e.g. the demo) and attempt to drag it outside.

While it has been challenging for us to get the effect perfect across all platform/rendering/drivers setups (some have e.g. a short flicker when creating a new window) it generally worked well in that setup with SDL2 and generally works much better if I revert this commit. Would you have another suggestion, or could we reinstate this or another hint or allow us to configure this?

multiviewportwith.SDL3.mp4

PS: as a side-note, the SDL Hints being global settings may be something to consider evolving for SDL3.
Our backends rely on SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH=1 and SDL_HINT_MOUSE_AUTO_CAPTURE=0 so we overwrite those hints hoping no users would complain about, but I can envision it becoming problematic. SDL3 may be a good time to rework those. On a case-by-case basis it may be good to replace them with additional metadata in events.

Ref:
https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_sdl3.cpp#L382

[slouken]

Hello,

We have recently implemented an SDL3 backend for Dear ImGui. (Ref: https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_sdl3.h + https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_sdl3.cpp)

This exact fix b4ebb3b is causing an issue with our integration of Multi-viewports which is an optional but highly-loved feature were users can drag Dear ImGui windows outside of the main window created by the user app, and our backend creates/destroy windows and render contexts to make the transition as smooth as possible.

Okay, I've re-added that hint and defaulted the new behavior on in 20a4e31.

Thanks for the feedback!

PS: as a side-note, the SDL Hints being global settings may be something to consider evolving for SDL3. Our backends rely on SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH=1 and SDL_HINT_MOUSE_AUTO_CAPTURE=0 so we overwrite those hints hoping no users would complain about, but I can envision it becoming problematic. SDL3 may be a good time to rework those. On a case-by-case basis it may be good to replace them with additional metadata in events.

Yes, we plan to review the hints in SDL3, but your use case feedback is very helpful. Please submit a new issue with an API update that makes sense for you, for tracking purposes. We may not implement that specific API, but we'll consider your needs as we evaluate the hints.

Thanks!

[ocornut]

Much appreciated, thanks for the fast feedback!
I'll open another issue later about hint suggestions.