PresentationInterval = PresentationInterval.Two in UWP

Hey guys,

This code doesn’t work in UWP games. Am I doing something wrong or is this a known bug? Is there any other way to set the presentation interval?

graphics.PreparingDeviceSettings += Graphics_PreparingDeviceSettings;
private void Graphics_PreparingDeviceSettings(object sender, PreparingDeviceSettingsEventArgs e)
    // This will not be applied correctly in UWP, Only interval One, not Two.
    e.GraphicsDeviceInformation.PresentationParameters.PresentationInterval = PresentInterval.Two;

Sorry you’re not getting responses (I saw your issue on Github), but when that happens it’s probably because no one’s around who can suitably answer the question. I unfortunately have no experience working with UWP and don’t even know what the presentation interval is.

Unfortunately, you’ll likely find MonoGame’s Issues page to be even less responsive than these forums. I posted an issue about a noticeable visual artifact with example screenshots and a barebones project to reproduce the problem about a month ago with no response.

MonoGame’s principal maintainers are few, and they’re usually busy.

Hello Toad, thanks for the moral support :slight_smile:

The lack of response was not entirely unforeseen as I realised UWP was a bit niche around here (it shouldn’t be imo as that is the route to the Microsoft Store after all) but as was pointed out to me by the guy writing a C# based VR engine (StereoKit), SharpDX is discontinued and no longer worked on so any issues we may encounter may well ultimately become, “That is just not fixable”?

This all makes me a bit sad as I’d hate to see Monogame die after the monumental effort it must have taken to get off the ground in the first place.

I had a look through your bug issue and have only this code comment to offer:

// Problems...setting this to true will cause runtime crash on Windows Store Release/Debug.
// It may also cause performance problems on Windows if not using dedicated GPU (set multisample count in PresentationParams event?
graphics.PreferMultiSampling = false;

In other words I’ve never used Multisampling options in Monogame because it (again) causes a crash in UWP. At least it did in MG3.7

As for PresentationInterval, that is simply referring to the VSync rate, the timing of the “electron gun” (as was) of the actual screen used for display:

0 = No VSync, draw our game to screen as often as possible. Usually with FixedTimeStep = false for max framerates. Tearing can occur in this mode (two or more different images on screen at once).
1 = Sync every VBlank, draw every time the “electron gun” goes back to start a new screen draw.
2 = Sync every second VBlank, draw every OTHER time the “electron gun” goes back to the start.
3 = Sync every third VBlank (No option in Monogame for this).
4 = Sync every fourth VBlank (No option in Monogame for this).

For example, VSync 4 might be desired if the user’s screen runs at 120Hz but you want your game to run at only 30FPS yet still maintain parity with VSync. IsFixedTimeStep = true can simulate this to a degree but without VSync = 4 you’d still be drawing more often than needed (nothing has updated) so it’s not optimal for performance and is not truly synced for that rock solid frame pacing.

Unity has a nice write up about it here: Unity - Scripting API: QualitySettings.vSyncCount

It’s also worth pointing out that Unity & UWP works just fine in this regard. Even their API for getting the current screen refresh rate works in UWP.

In the end I fear that alot of these graphical bugs and issues with Monogame will end up not being addressed/fixable due to SharpDX so we use it at our own peril, understanding the risks and compromises we make in terms of features or platforms we target. It’s not always easy though as the first instinct/assumption is that we’ve done something wrong ourselves and in some cases of course we have.


Cool, thanks for the info. Though what would you do if you had a user with a 75 Hz monitor, like me? You wouldn’t be able to get a 30 fps V-sync through any presentation interval. My monitor does have FreeSync, though, so using FixedTimeStep might have decent results.

Interesting, I don’t think I was aware of that. Well, the bright side is, MonoGame’s maintainers could always fork SharpDX and fix any MonoGame-relevant bugs themselves if needed. I unfortunately could not hope to fix any such bugs myself.

I do like MonoGame, despite the occasional bug. It’s comfortable and familiar. But I’m also thinking about trying out Godot for a future project, mainly due to it’s built-in physics capabilities.

I don’t know about modern VSync solutions like FreeSync, G-Sync, Adaptive VSync etc but I think they’re mostly used to slow down the refresh rate of the monitor if your GPU is not keeping up with the natural sync rate of your monitor (thus getting stutter and or tearing).

So my guess would be that if a Fixed Time Step in game was enabled then if the game was only spitting out a frame every 1/60th of a second (regardless of VSync settings), then FreeSync would detect “Game Displaying Slower than 75Hz” and reduce the refresh rate of the monitor to match…which would be perfect, the game would be running at 60fps and the screen would be running at 60Hz, hopefully matching 1:1 and 100% in sync.

I’d be interested to see if it worked like that in practice, especially for a 2D game, which is pretty much all I use Monogame for.

I too have a great affection for Monogame, I followed Managed DirectX right from the start and was delighted to see Monogame rise from the ashes of Xna. In a way, it’s simplicity is it’s strength, you just have a few methods, Init, Update and Draw and off you go, it’s all for you to discover.

1 Like

Yep, that sounds exactly right to me.

Yeah, that’s probably what drew me to MonoGame in the first place and what keeps me using it as well, besides the aforementioned familiarity.