Setting window to fullscreen on a monitor (SDL_WINDOW_FULLSCREEN) other than the primary will inevitably move the window back to primary monitor.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• work in progress patch (SDL-bugzilla-4540-workinprogress-RYAN1.diff.txt, text/plain, 2020-02-12 05:36:37 +0000, 17500 bytes)
• second attempt at migrating to a new display (SDL-bugzilla-4540-workinprogress-RYAN2.diff.txt, text/plain, 2020-04-07 04:06:43 +0000, 24420 bytes)

Reported in version: 2.0.9
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2019-03-07 05:12:56 +0000, Darrell wrote:

Hello, I’m trying to see if can get SDL2 to go fullscreen with a video mode change (SDL_WINDOW_FULLSCREEN) on other monitors than that of my primary monitor.

However, when I call SDL_SetWindowFullscreen after moving the window to another monitor, it will seemingly set it’s size, video mode, and position correctly but then will move the window back to the primary monitor, while keeping the video mode of the desired monitor, making both monitors have the same video mode while showing the window on the wrong monitor.

I’ve made a test app solely for the purpose of figuring this out, found here: https://github.com/Salads/SDL2-WindowMode-Test/blob/master/Source/Main.cpp (uses ImGui + imgui_sdl)

Running with the debug build of SDL2, I verified that SDL_SetWindowFullscreen works (if I first set it to windowed mode and set the position and size to that of another monitor) but when ImGuiSDL::Render(ImGui::GetDrawData()); is called, it switches the window back to the primary monitor. Internally, ImGuiSDL uses SDL_RenderFillRect, here’s a pseudo stack trace from there:

SDL_RenderFillRect
D3D_ActivateRenderer
D3D_Reset
IDirect3DDevice9_Reset - Window moves back to primary monitor here at render\direct3d\SDL_render_d3d.c:355

This also happens on another app that uses SDL2 as well, where it simply gets the system window handle and uses that to go on and initialize directX. I can try to see if the stack trace is somewhat similar on the other app since it takes another approach to using SDL2.

On 2019-03-07 08:37:58 +0000, Darrell wrote:

Tracing through the other app I mentioned, I found that it also has the window move back to the primary monitor when the D3D9Device is reset, so this may have something to do with how DirectX works...?

On 2019-07-30 17:49:36 +0000, Ryan C. Gordon wrote:

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

On 2019-09-20 20:47:38 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:40 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2020-02-11 17:49:58 +0000, Sam Lantinga wrote:

Ryan, do you have a multi-monitor setup to debug this?

On 2020-02-11 18:48:12 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 5)

Ryan, do you have a multi-monitor setup to debug this?

I do, I'm looking at this one right now.

--ryan.

On 2020-02-11 18:49:44 +0000, Sam Lantinga wrote:

I think the D3D device instance has a handle to the monitor, so we may need to update that when the window position changes.

On 2020-02-11 19:43:09 +0000, Ryan C. Gordon wrote:

The imgui test app in this bug is kinda awesome. :) I can reproduce it here, working on tracking it down.

--ryan.

On 2020-02-11 20:18:11 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 7)

I think the D3D device instance has a handle to the monitor, so we may need
to update that when the window position changes.

You are probably correct; during SDL_RenderPresent, after the fullscreen change, D3D_RunCommandQueue tries to activate its stuff at the start, which calls D3D_Reset to trash everything and rebuild it due to the window change.

In there, IDirect3DDevice9_Reset() gets called, and before that call returns the window is back on the primary display.

I'll read up and figure it out, but this is creeping towards being solved now.

--ryan.

On 2020-02-11 22:38:25 +0000, Ryan C. Gordon wrote:

I’m guessing it’s because IDirect3DDevice9_CreateDevice has to specify a display adapter and Reset doesn’t let you choose a different one. We probably have to fully tear down And rebuild the D3D device in this scenario if this is the culprit.

(Obviously the window can safely drag between displays or be moved there programmatically, it’s just the fullscreening causing a problem here.)

--ryan.

On 2020-02-12 00:33:47 +0000, Sam Lantinga wrote:

Yup, that's probably true. If we go fullscreen on a different display than we started with, we need to recreate the D3D device on that display.

Let's go ahead and fix this after 2.0.12 is out.

On 2020-02-12 01:48:07 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 11)

Yup, that's probably true. If we go fullscreen on a different display than
we started with, we need to recreate the D3D device on that display.

Let's go ahead and fix this after 2.0.12 is out.

Wait, I’m mostly there, just have to move some code from D3D_CreateRenderer to a separate function.

--ryan.

On 2020-02-12 05:36:37 +0000, Ryan C. Gordon wrote:

Created attachment 4205
work in progress patch

Wait, I’m mostly there, just have to move some code from D3D_CreateRenderer
to a separate function.

Okay, nevermind, this patch is pretty big and still not right (among other things, we lose all the textures when the device is recreated), but I'll post the work-in-progress here for when we revisit.

--ryan.

On 2020-04-07 04:06:43 +0000, Ryan C. Gordon wrote:

Created attachment 4296
second attempt at migrating to a new display

(In reply to Ryan C. Gordon from comment # 13)

Okay, nevermind, this patch is pretty big and still not right (among other
things, we lose all the textures when the device is recreated), but I'll
post the work-in-progress here for when we revisit.

Been fighting with this all week, and now I can move this program to a different display and keep the textures, by saving them all off before destroying everything and recreating new textures on the new device with the saved-off data. This adds some complexity, but as a side-benefit, we don't even have to send an SDL_RENDER_TARGETS_RESET event in this case.

I'm attaching the current work-in-progress, because I have to take a break from this. It's still a little crashy, so it isn't ready for revision control, but this actually almost works now.

We'll have to decide if all this heavy-lifting is worth it, though. Now that I can see what's involved, I'm a little nervous about it. It's cool when it works, but I'm still not sure we shouldn't have just refused the fullscreen request in the first place.

--ryan.