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

[DX] Improve window handling #5585

Merged
merged 27 commits into from Aug 14, 2017

Conversation

Projects
None yet
10 participants
@Jjagg
Contributor

Jjagg commented Mar 15, 2017

This tackles some of the issues with stuff like minimizing/maximizing the window and full screen switching. The largest fix is that now the back buffer size is properly updated when switching to full screen. Other fixes include correctly switching from hardware to soft full screen and back, minimizing the window when the windows key is pressed only when in hard full screen mode and raising the ClientSizeChanged event when switching window state (e.g. minimizing the window).

I also moved some responsibilities from WinFormsGamePlatform to WinFormsGameWindow because it made more sense there.

An issue that is not solved with this is changing the back buffer size while in hard full screen. That will not change the display mode while it should be able to do that. Can anyone more familiar with D3D pitch in? Do we just switch out of full screen and back in or is there a better way to do this?

There's another problem when creating a device in soft full screen (this didn't work before either). The back buffer size won't be right, which results in a blank screen (is that normal?). The cause of this problem is WinForms related. It seems the form ClientBounds are not updated immediately when changing the WindowState to Maximized when the form is not yet visible.

fixes #5533
Also fixes the DirectX issue from #5530.
@aienabled, @Thraka

@Thraka

This comment has been minimized.

Show comment
Hide comment
@Thraka

Thraka Mar 31, 2017

Let's get this released! 👍

Thraka commented Mar 31, 2017

Let's get this released! 👍

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Apr 4, 2017

Contributor

There's another problem when creating a device in soft full screen

Worked around this by resizing backbuffer when initializing the window.

Still would like to get the resize while in full screen thing fixed before merging this.

Contributor

Jjagg commented Apr 4, 2017

There's another problem when creating a device in soft full screen

Worked around this by resizing backbuffer when initializing the window.

Still would like to get the resize while in full screen thing fixed before merging this.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Apr 10, 2017

Contributor

Note to self: use swapChain.ResizeTarget for resolution switch in fullscreen.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/bb205075(v=vs.85).aspx

When that works this is ready for review and hopefully merge :)
I started writing a simple project for testing windowing functionality and presentation parameters, that should make testing things like this easier in the future.

Contributor

Jjagg commented Apr 10, 2017

Note to self: use swapChain.ResizeTarget for resolution switch in fullscreen.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/bb205075(v=vs.85).aspx

When that works this is ready for review and hopefully merge :)
I started writing a simple project for testing windowing functionality and presentation parameters, that should make testing things like this easier in the future.

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 4, 2017

Contributor

@Jjagg How's this coming along? I recently synced my MonoGame fork with the latest code and found an issue when switching out of soft-fullscreen mode which this seems to fix. I plan to deploy this in an experimental build to my users to better test it and see if any other issues turn up.

Contributor

MichaelDePiazzi commented May 4, 2017

@Jjagg How's this coming along? I recently synced my MonoGame fork with the latest code and found an issue when switching out of soft-fullscreen mode which this seems to fix. I plan to deploy this in an experimental build to my users to better test it and see if any other issues turn up.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg May 4, 2017

Contributor

This needs just a little more work. I've been really busy and not sure when things will ease up a little. But I'll try and get this fixed asap :)

Contributor

Jjagg commented May 4, 2017

This needs just a little more work. I've been really busy and not sure when things will ease up a little. But I'll try and get this fixed asap :)

@Thraka

This comment has been minimized.

Show comment
Hide comment
@Thraka

Thraka May 4, 2017

@Jjagg Thanks for your work on this. I'm really looking forward to it 👍 👍 👍

Thraka commented May 4, 2017

@Jjagg Thanks for your work on this. I'm really looking forward to it 👍 👍 👍

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 5, 2017

Contributor

@Jjagg No worries, I can totally empathise with you on that! Thanks for the update :)

Contributor

MichaelDePiazzi commented May 5, 2017

@Jjagg No worries, I can totally empathise with you on that! Thanks for the update :)

MichaelDePiazzi added a commit to MichaelDePiazzi/MonoGame that referenced this pull request May 12, 2017

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 12, 2017

Member

@tomspilman Mac build bot got stuck, it has been building this PR for ~2 hours right now.

Member

cra0zy commented May 12, 2017

@tomspilman Mac build bot got stuck, it has been building this PR for ~2 hours right now.

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 15, 2017

Contributor

@Jjagg I just found a bug in this PR - In soft-fullscreen mode, you can no longer set a different resolution than the desktop resolution. e.g. If I try set the resolution to 1280x720, it remains at my desktop resolution of 1920x1080.

Contributor

MichaelDePiazzi commented May 15, 2017

@Jjagg I just found a bug in this PR - In soft-fullscreen mode, you can no longer set a different resolution than the desktop resolution. e.g. If I try set the resolution to 1280x720, it remains at my desktop resolution of 1920x1080.

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 15, 2017

Member

@Jjagg I just found a bug in this PR - In soft-fullscreen mode, you can no longer set a different resolution than the desktop resolution. e.g. If I try set the resolution to 1280x720, it remains at my desktop resolution of 1920x1080.

This is how it should be, it was a bug that you could change resolution in soft fullscreen mode.

Member

cra0zy commented May 15, 2017

@Jjagg I just found a bug in this PR - In soft-fullscreen mode, you can no longer set a different resolution than the desktop resolution. e.g. If I try set the resolution to 1280x720, it remains at my desktop resolution of 1920x1080.

This is how it should be, it was a bug that you could change resolution in soft fullscreen mode.

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 15, 2017

Contributor

This is how it should be, it was a bug that you could change resolution in soft fullscreen mode.

Really, since when? It's worked like this for years in WinDX, and my game kinda depends on this behaviour... 😟

Contributor

MichaelDePiazzi commented May 15, 2017

This is how it should be, it was a bug that you could change resolution in soft fullscreen mode.

Really, since when? It's worked like this for years in WinDX, and my game kinda depends on this behaviour... 😟

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 15, 2017

Member

Really, since when? It's worked like this for years in WinDX, and my game kinda depends on this behaviour... 😟

You can just change the viewport to get that behavior.

Member

cra0zy commented May 15, 2017

Really, since when? It's worked like this for years in WinDX, and my game kinda depends on this behaviour... 😟

You can just change the viewport to get that behavior.

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 15, 2017

Contributor

You can just change the viewport to get that behavior.

@cra0zy Not sure if I'm missing something, but changing the viewport does not scale it to fullscreen like it was doing before. e.g. If I set the viewport to 1280x720, then instead of filling the entire screen like I was hoping for, it just draws to a smaller 1280x720 area in the top corner of the full 1920x1280 screen. This is basically what I'm doing:

_graphicsDeviceManager.IsFullScreen = true;
_graphicsDeviceManager.HardwareModeSwitch = false;
_graphicsDeviceManager.ApplyChanges();
_graphicsDeviceManager.GraphicsDevice.Viewport = new Viewport(0, 0, 1280, 720);

Is this right?

Contributor

MichaelDePiazzi commented May 15, 2017

You can just change the viewport to get that behavior.

@cra0zy Not sure if I'm missing something, but changing the viewport does not scale it to fullscreen like it was doing before. e.g. If I set the viewport to 1280x720, then instead of filling the entire screen like I was hoping for, it just draws to a smaller 1280x720 area in the top corner of the full 1920x1280 screen. This is basically what I'm doing:

_graphicsDeviceManager.IsFullScreen = true;
_graphicsDeviceManager.HardwareModeSwitch = false;
_graphicsDeviceManager.ApplyChanges();
_graphicsDeviceManager.GraphicsDevice.Viewport = new Viewport(0, 0, 1280, 720);

Is this right?

@cra0zy

This comment has been minimized.

Show comment
Hide comment
@cra0zy

cra0zy May 15, 2017

Member

You know, sometimes I forget some important stuff like the difference in what viewport is in GL and XNA... so in short there are 2 ways that I know of to scale your spritebatch game:

  1. Create scale matrix and feed it to transform component in your spritebatch begin methods
  2. Create a rendertarget2d and render everything to it, then just render it stretched (or scaled)
Member

cra0zy commented May 15, 2017

You know, sometimes I forget some important stuff like the difference in what viewport is in GL and XNA... so in short there are 2 ways that I know of to scale your spritebatch game:

  1. Create scale matrix and feed it to transform component in your spritebatch begin methods
  2. Create a rendertarget2d and render everything to it, then just render it stretched (or scaled)
@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 15, 2017

Contributor

@cra0zy I was afraid you were going to say that. Method 1 is not practical at all for me. Method 2 could be an option, but it's gonna require a few changes and is going to add another fullscreen blit which isn't really ideal.

I'm kinda surprised being able to specify a different resolution for soft fullscreen was considered a bug. To me, this ability was a benefit of the mode and was how I'd expect it to work. Many other games allow you to specify a different resolution in soft fullscreen mode. It kinda sucks that the user would have to now emulate this behaviour under MonoGame... :/

Contributor

MichaelDePiazzi commented May 15, 2017

@cra0zy I was afraid you were going to say that. Method 1 is not practical at all for me. Method 2 could be an option, but it's gonna require a few changes and is going to add another fullscreen blit which isn't really ideal.

I'm kinda surprised being able to specify a different resolution for soft fullscreen was considered a bug. To me, this ability was a benefit of the mode and was how I'd expect it to work. Many other games allow you to specify a different resolution in soft fullscreen mode. It kinda sucks that the user would have to now emulate this behaviour under MonoGame... :/

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg May 15, 2017

Contributor

There was a bit of discussion about how to handle backbuffer/viewport resolution mismatch in #5530. Read down from #5530 (comment) if you're interested. tldr: scaling is more convenient, but forcing desktop resolution is more portable. No real decision has been made, so I just implemented what I thought was best.

Contributor

Jjagg commented May 15, 2017

There was a bit of discussion about how to handle backbuffer/viewport resolution mismatch in #5530. Read down from #5530 (comment) if you're interested. tldr: scaling is more convenient, but forcing desktop resolution is more portable. No real decision has been made, so I just implemented what I thought was best.

@MichaelDePiazzi

This comment has been minimized.

Show comment
Hide comment
@MichaelDePiazzi

MichaelDePiazzi May 15, 2017

Contributor

tldr: scaling is more convenient, but forcing desktop resolution is more portable.

Ok. I can't really comment from a portability point of view as I've only been dealing with Windows DirectX so far.

No real decision has been made, so I just implemented what I thought was best.

Fair enough. I'll probably wait until a decision's been made then before I go changing how this works in my game. In the meantime, I'll have to maintain the previous behaviour and try fix the soft-fullscreen issues I was having separately.

Contributor

MichaelDePiazzi commented May 15, 2017

tldr: scaling is more convenient, but forcing desktop resolution is more portable.

Ok. I can't really comment from a portability point of view as I've only been dealing with Windows DirectX so far.

No real decision has been made, so I just implemented what I thought was best.

Fair enough. I'll probably wait until a decision's been made then before I go changing how this works in my game. In the meantime, I'll have to maintain the previous behaviour and try fix the soft-fullscreen issues I was having separately.

@Thraka

This comment has been minimized.

Show comment
Hide comment
@Thraka

Thraka May 15, 2017

Which ever way it works, please make sure it works the same for each backend. I don't want to have to code specific things for if it's using OpenGL or DX.

Thraka commented May 15, 2017

Which ever way it works, please make sure it works the same for each backend. I don't want to have to code specific things for if it's using OpenGL or DX.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg May 15, 2017

Contributor

Absolutely, consistency across platforms is a high priority.

Contributor

Jjagg commented May 15, 2017

Absolutely, consistency across platforms is a high priority.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Jun 22, 2017

Contributor

WinForms/DX is now working correctly in this branch in all cases I tested, including switching resolutions at full screen and switching between hard and soft fullscreen!

Contributor

Jjagg commented Jun 22, 2017

WinForms/DX is now working correctly in this branch in all cases I tested, including switching resolutions at full screen and switching between hard and soft fullscreen!

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Jun 22, 2017

Contributor

Anyone interested in this, please do test this and report if there are any issues left.
Here's the file I used for testing this PR: https://gist.github.com/Jjagg/2a30c9214d38bcc5ec79665ff762df6b

Note that this locks resolution in soft full screen to the desktop resolution.

I still need to test UWP before this is safe to merge.

Contributor

Jjagg commented Jun 22, 2017

Anyone interested in this, please do test this and report if there are any issues left.
Here's the file I used for testing this PR: https://gist.github.com/Jjagg/2a30c9214d38bcc5ec79665ff762df6b

Note that this locks resolution in soft full screen to the desktop resolution.

I still need to test UWP before this is safe to merge.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Jun 22, 2017

Contributor

So UWP (tested on win10 desktop) is not doing things right at all... :/ It correctly resizes the backbuffer when the window is resized (even during resizing), but changing the back buffer size does not change the window size and it does not seem to do mode switched full screen at all. The behaviour in the develop branch and this branch is exactly the same though, so it's not a blocker.

So this is good to go IMO! :)
Again, anyone please test this with MG DX to confirm it's good for merge! You can use the gist linked in my previous comment for a quick test.

When this is merged I'll tackle the windowing in DesktopGL and make sure its behaviour is the same as DX.

Contributor

Jjagg commented Jun 22, 2017

So UWP (tested on win10 desktop) is not doing things right at all... :/ It correctly resizes the backbuffer when the window is resized (even during resizing), but changing the back buffer size does not change the window size and it does not seem to do mode switched full screen at all. The behaviour in the develop branch and this branch is exactly the same though, so it's not a blocker.

So this is good to go IMO! :)
Again, anyone please test this with MG DX to confirm it's good for merge! You can use the gist linked in my previous comment for a quick test.

When this is merged I'll tackle the windowing in DesktopGL and make sure its behaviour is the same as DX.

@nkast

This comment has been minimized.

Show comment
Hide comment
@nkast

nkast Jun 22, 2017

Contributor

Why clamp the backbuffer size to display size? Did XNA had a similar limitation?

In fullscreen the backbuffer will be scaled automatically to the swapchan size, no mater if it's lower or higher resolution. In window mode it will look strange but nonetheless that's up to the dev.

changing the back buffer size does not change the window size

We can Try to fix that on UWP but it's not guaranteed to work.

Contributor

nkast commented Jun 22, 2017

Why clamp the backbuffer size to display size? Did XNA had a similar limitation?

In fullscreen the backbuffer will be scaled automatically to the swapchan size, no mater if it's lower or higher resolution. In window mode it will look strange but nonetheless that's up to the dev.

changing the back buffer size does not change the window size

We can Try to fix that on UWP but it's not guaranteed to work.

@Jjagg

This comment has been minimized.

Show comment
Hide comment
@Jjagg

Jjagg Jun 22, 2017

Contributor

I was experimenting with this because Windows clamps the window size to the desktop resolution. That makes the backbuffer and window sizes mismatch and the back buffer will be scaled. XNA does not clamp back buffer size though, so I will remove the clamping.

Contributor

Jjagg commented Jun 22, 2017

I was experimenting with this because Windows clamps the window size to the desktop resolution. That makes the backbuffer and window sizes mismatch and the back buffer will be scaled. XNA does not clamp back buffer size though, so I will remove the clamping.

@Jure-BB

This comment has been minimized.

Show comment
Hide comment
@Jure-BB

Jure-BB Jun 22, 2017

Contributor

Good work @Jjagg. I'll test on MG DX and report back.

Contributor

Jure-BB commented Jun 22, 2017

Good work @Jjagg. I'll test on MG DX and report back.

@Jure-BB

This comment has been minimized.

Show comment
Hide comment
@Jure-BB

Jure-BB Jun 23, 2017

Contributor

My test results: Resizing & maximizing window now work without issues, which is great. Full screen toggle also works without issues in HW mode.

First minor issue I found is that when using WinKey+Left/Right shortcuts (in Win 10) to move game window, won't fire size changed events and everything will be squashed & stretched when window is resized and snapped to the edge. Very low priority issue IMO.

Other issues are related to how MG handles multiple monitors (may be better fit for another PR?). MG is only using first adapter/monitor, even if game window is on another monitor. Toggling to fullscreen in SW mode on second display results in wrong resolution as we are querying CurrentDisplayMode on first display. Is SW fullscreen resolution limited to single resolution (only current desktop resolution) by design? Also querying SupportedDisplayModes when game is on second display returns wrong results (values from 1st display).

Contributor

Jure-BB commented Jun 23, 2017

My test results: Resizing & maximizing window now work without issues, which is great. Full screen toggle also works without issues in HW mode.

First minor issue I found is that when using WinKey+Left/Right shortcuts (in Win 10) to move game window, won't fire size changed events and everything will be squashed & stretched when window is resized and snapped to the edge. Very low priority issue IMO.

Other issues are related to how MG handles multiple monitors (may be better fit for another PR?). MG is only using first adapter/monitor, even if game window is on another monitor. Toggling to fullscreen in SW mode on second display results in wrong resolution as we are querying CurrentDisplayMode on first display. Is SW fullscreen resolution limited to single resolution (only current desktop resolution) by design? Also querying SupportedDisplayModes when game is on second display returns wrong results (values from 1st display).

@RefactoredGames

This comment has been minimized.

Show comment
Hide comment
@RefactoredGames

RefactoredGames Jul 22, 2017

Can this be merged now..?

RefactoredGames commented Jul 22, 2017

Can this be merged now..?

@Jure-BB

This comment has been minimized.

Show comment
Hide comment
@Jure-BB

Jure-BB Aug 14, 2017

Contributor

Could this be merged @tomspilman?

Contributor

Jure-BB commented Aug 14, 2017

Could this be merged @tomspilman?

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 14, 2017

Contributor

Merging.

Contributor

KonajuGames commented Aug 14, 2017

Merging.

@KonajuGames KonajuGames merged commit 1a9466e into MonoGame:develop Aug 14, 2017

5 checks passed

Build Mac, iOS, and Linux Finished TeamCity Build MonoGame :: Build Mac : Running
Details
Build Windows, Web, Android, and OUYA Finished TeamCity Build MonoGame :: Build Windows : Running
Details
Package Mac and Linux Finished TeamCity Build MonoGame :: Package Mac and Linux : Running
Details
Package Windows SDK Finished TeamCity Build MonoGame :: Package Windows : Running
Details
Test Windows Finished TeamCity Build MonoGame :: Test Windows : Tests passed: 1094, ignored: 11
Details
#if WINDOWS
CorrectBackBufferSize();
#endif

This comment has been minimized.

@tomspilman

tomspilman Aug 14, 2017

Member

Can we do this in a better way that doesn't involve an #if WINDOWS here? We are trying to reduce the #ifs and not increase them.

@tomspilman

tomspilman Aug 14, 2017

Member

Can we do this in a better way that doesn't involve an #if WINDOWS here? We are trying to reduce the #ifs and not increase them.

This comment has been minimized.

@Jjagg

Jjagg Aug 15, 2017

Contributor

We could do it with partial stuff, but I think it would be good if all platforms eventually implemented this method. The #if would be temporary.

Sent from my Motorola Moto G (5) using FastHub

@Jjagg

Jjagg Aug 15, 2017

Contributor

We could do it with partial stuff, but I think it would be good if all platforms eventually implemented this method. The #if would be temporary.

Sent from my Motorola Moto G (5) using FastHub

This comment has been minimized.

@cra0zy

cra0zy Aug 15, 2017

Member

This comment has been minimized.

@cra0zy

cra0zy Aug 15, 2017

Member

Oh wait, you are also calling it on reset, yea, partial method would be the best IMO

@cra0zy

cra0zy Aug 15, 2017

Member

Oh wait, you are also calling it on reset, yea, partial method would be the best IMO

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 22, 2017

Contributor

This PR may have a side effect shown in #5885. Alt+tabbing from fullscreen results in the taskbar button for the app disappearing, i.e. the window closed, but the process is still running. I'm having a quick look at this now, but if anyone else can help, that would be great too.

Contributor

KonajuGames commented Aug 22, 2017

This PR may have a side effect shown in #5885. Alt+tabbing from fullscreen results in the taskbar button for the app disappearing, i.e. the window closed, but the process is still running. I'm having a quick look at this now, but if anyone else can help, that would be great too.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 22, 2017

Contributor

I've got a fix that I'll be submitting now. When it was deactivating the process while in exclusive full-screen mode, it wasn't changing the swapchain out of exclusive mode. It now forces it out of exclusive mode and minimizes the window.

Contributor

KonajuGames commented Aug 22, 2017

I've got a fix that I'll be submitting now. When it was deactivating the process while in exclusive full-screen mode, it wasn't changing the swapchain out of exclusive mode. It now forces it out of exclusive mode and minimizes the window.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 22, 2017

Contributor

Well, that was DirectX fixed. GL doesn't exit exclusive mode either, or remove the window. Fixing that now.

Contributor

KonajuGames commented Aug 22, 2017

Well, that was DirectX fixed. GL doesn't exit exclusive mode either, or remove the window. Fixing that now.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 22, 2017

Contributor

Fixed GL. Set the SDL hint to minimize on focus loss when going to exclusive full-screen mode, otherwise the hint is cleared.

Contributor

KonajuGames commented Aug 22, 2017

Fixed GL. Set the SDL hint to minimize on focus loss when going to exclusive full-screen mode, otherwise the hint is cleared.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Aug 22, 2017

Contributor

#5887 submitted to fix DirectX and OpenGL.

Contributor

KonajuGames commented Aug 22, 2017

#5887 submitted to fix DirectX and OpenGL.

@vpenades

This comment has been minimized.

Show comment
Hide comment
@vpenades

vpenades Aug 22, 2017

Contributor

From past experiences, I know handling windowed/fullscreen is a total nightmare.

Regarding Swap Chain buffer size matching the actual window... instead of depending on window resize events, wouldn't be more robust to check the SwapChain size against the actual window size at the beginning of every render frame?

I believe that all resize events are intended to be used by event based applications... but given monogame runs continuosly...

Contributor

vpenades commented Aug 22, 2017

From past experiences, I know handling windowed/fullscreen is a total nightmare.

Regarding Swap Chain buffer size matching the actual window... instead of depending on window resize events, wouldn't be more robust to check the SwapChain size against the actual window size at the beginning of every render frame?

I believe that all resize events are intended to be used by event based applications... but given monogame runs continuosly...

@Jjagg Jjagg deleted the Jjagg:dxwin branch Mar 4, 2018

nkast added a commit to nkast/MonoGame that referenced this pull request Jun 26, 2018

[DX] Improve window handling (MonoGame#5585)
* [DX] Improve window handling

* Update back buffer size when switching to full screen

* Fix dirty flag on early exit in GDM.ApplyChanges

* Restore full screen after minimizing the window

* Allow mode switching from the start

* Fix DesktopGL build

* Fix ClientSize raised before back buffer resize

* Ignore resize events after switching soft full screen

* VS done too much renamin'

* Fix UWP build

* Fix intializing in soft full screen mode

* Resizing in hw full screen and cleanup things a bit

* Fix hard full screen on startup and disposal

Hardware full screen failed when set in the game constructor because there
was no swapchain yet to get the output from. If there is no swapchain yet,
the current method gets the primary output by enumerating adapters and
getting the first, then getting the first output from that adapter.

When exiting a game while in full screen I sometimes got stuck with a
black screen. That was fixed by making sure we exit full screen when
disposing a GraphicsDevice.

* Remove unused event

* Clamp backbuffer size to display size

* Make OnPresentationChanged for WinForms internal

* Fix DesktopGL build

* Fix Web build

* Fix mobile build

* Only correct back buffer size for desktop platforms

* Don't change DesktopGL to make this more mergeable

* Don't limit back buffer size

* Update Adapter when display changes

Added a check after a window is moved (or resized) that updates the
GraphicsAdapter of the GraphicsDevice to the adapter that is rendering the
display that the window is on (because that might have changed).

* Detect window size change through Win10 hotkeys

* Catch ContainingOutput exception on headless devices

* Don't center window after move with hotkeys

* Fix resize through code raising ClientSizeChanged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment