Win 8 Store App Performance on Touch Devices

[AdamHill]

We’ve finished porting our game to MonoGame Windows 8 Store. It’s mostly gone fantastic, but we’ve hit a performance roadblock on certain devices, and are struggling to identify and fix the root cause.

The original desktop XNA 4.0 version of the game ran smoothly at 62.5fps on all our devices. Our MonoGame port runs smoothly at 62.5fps on all our desktop devices including an old Core 2 Duo, however runs at around 30–40fps on Lenovo i5 & i7 Horizons and an i7 Intel Ultrabook. We’ve disabled various aspects of the game to locate what is responsible, but have some surprising findings. To clarify, that’s a Core 2 Duo out-performing 2 different models of i7 on a specifically-CPU basis.

The original XNA version ran at near 100% CPU of a single core (single-threaded). This was to be expected as we have an empty loop to take up the remaining frame time to prevent the game running too fast.

In the MonoGame Windows 8 version we cannot break around ~30% CPU of a single core (again, single-threaded) despite our frame rate being devastated, running at a very shaky 30–40fps, or worse. It seems like our CPU is being artificially limited in Windows 8.

We have experimented to no avail with the following:

• Commenting out MonoGame’s Microsoft.Xna.Game.Tick()'s Task.Delay(SleepTime).Wait();
• VSync on and off
• Removing our arbitrary frame rate limiter
• FixedTimeStep = true & false (this helped a bit)
• Removing all game-specific use of Touch-related code
• Reducing Microsoft.Xna.Framework.Input.Touch.TouchPanelState’s MaxEvents from 100 to 10

To clarify we appear to have two potentially related issues:

• In general the performance is significantly (i.e. not good enough for release) worse than the desktop version running almost the same code.
• The devices which don’t perform well are (co-incidentally?) Touch Screen devices, with batteries but testing was done plugged into mains on High Performance power setting.

Also, we’ve seen this possibly-related issue:

• http://monogame.codeplex.com/discussions/405776

We do indeed have even more performance trouble when holding down a number of fingers on a touch device. Usually this means the framerate will become increasingly erratic, varying around 10fps lower than before. This is even though we’ve disabled any code which listens to touch.

Unfortunately we’re now lost for ideas. The common link appears to be touch, but even if the game makes zero reference to or use of touch the issue is still there. On touch devices our access to the CPU appears arbitrarily limited to ~30% of the available CPU time, even though the game clearly needs more, and is losing FPS as a result.

Does anyone have any suggestions where we can look or what we could try? We have a near-finished MonoGame Windows 8 Store game almost ready to ship but dead in the water due to this.

I have some screenshots of CPU graphs I’ll post if as a new user I’m able…

[Tom]

@AdamHill

It seems like our CPU is being artificially limited in Windows 8.

Probably not artificially… this sounds exactly like you are GPU bound. If for whatever reason the GPU is falling behind the CPU will sit around waiting for it to catch up.

This might be obvious, but I have to mention it. Have you tried installing the latest video card drivers?

[nkast]

Have tried to turn off touch feedback?
(the little circles that appear bellow your finger)
You can turn this off globally in windows settings. If you find this to be an improvement you can then turn it off programatically in your app.

[nkast]

Is it possible to disable the touch driver and give us some more feedback?
Which version of MG are you using?

So, the problem is when you run a metro version of the game on touch device or the desktop version? How those two compare on the same device? How XNA run on it? (the core duo might have a better GPU).

[AdamHill]

Hi Tom,

Thanks for getting back. I’ve just updated the driver to make 100% sure it’s not that, and I’m still getting under 40fps in “Metro”, so we can rule that one out.

We’re using the latest MonoGame. We’ve tried both the DLL and building our own source.

There are three reasons we’ve assumed it’s not GPU bound:

1. Draw passes are completing in 2–3ms. Unless there’s something wrong with our approach for measuring that then I don’t understand why that wouldn’t be higher if it is GPU bound.
2. The same drawing operations as sent from the desktop version aren’t limiting performance of the game on the same hardware, e.g. if it was fill rate why is that hurting Win 8 version and not the XNA version (obviously the Win 8 ones are very slightly modified for Dx11, but only very slightly)
3. We’ve tried bypassing the draw altogether for some of the fullscreen FX, which does help, but only a bit. The fps goes up a little, but it’s still the Update length which is erratic rather than the now near-zero Draw length.

We do have some shaders running, and one (a texture-mapped warp grid effect like Geometry Wars) of them is certainly one of the costliest elements of the game. Our frustration is that it’s fine on XNA 4, though.

I’ve also tried both the flavours of MonoGame Windows 8 Store App project, i.e. XAML and not XAML. No apparent difference.

We’ll try and produce a very cut-down example of the issue if we can. I can give you a link to the two full projects if that helps.

Hi Nkast,

We’ve tried disabling touch feedback. The problem is only with the Metro MonoGame version, a very similar version runs absolutely fine on the same device via desktop “old-skool” XNA 4.0. Of course with the code being a little different there is always the possibility we’ve messed up, so I’m trying to build a test project to prove / highlight the issue at the moment. I’ll post a link soon. I’ll also shortly be backporting some of the changes from the Metro version to the old desktop version to limit the chance it’s a slip.

[Tom]

@AdamHill

Draw passes are completing in 2–3ms. Unless there’s something wrong with our approach for measuring

What is important to test in your case here is the time to GraphicsDevice.Present() the back buffer. Put a timer around the base.Draw(GameTime) in your main game Draw call. Internally that calls GraphicsDevice.Present().

If you are having stalls from the GPU for whatever reason you’ll see the present time be really slow at times.

@AdamHill

desktop version aren’t limiting performance of the game on the same hardware

That is a pretty good indication that it isn’t a GPU performance issue. However XNA is DX9 and MonoGame is DX11, so there could possibly be differences.

@AdamHill

We’ll try and produce a very cut-down example of the issue if we can.

That is usually best… if you have a fairly simple example that exhibits the issue it makes it very simple to get fixed or figured out.

I’ll be watching for it.

[AdamHill]

I have made a test solution based on our background that demonstrates the issue across the platforms (XNA 4 desktop vs MonoGame Windows 8 Store). It’s fairly small but not ultra-simple as I wanted to reproduce the same rendering setup we use in case that’s to blame.

Possible avenues of investigation:

• Please treat our method of timing with suspicion, just in case we’re doing it wrong which would of course explain a lot. You can see it wired into Game1.cs, using our Testing/FpsCounter.cs component.

Project differences:

• Game1.cs, lines 38–39 & lines 215–216
• Content/Shaders are slightly different due to Dx9/11 - in theory they should do the same thing logically

Notes on using the projects:

• VSync can be switched on/off in Game1.cs, line 227, last parameter
• Our somewhat dodgy frame limiter code can be enabled/disabled in Settings.cs “LimitFps”
• I’m hoping the font used is a default one, feel free to substitute as needed
• You’ll need to Alt+F4 to quit the XNA version
• Adjust the “strain” by changing the maxWarpGridPoints, Game1.cs, line 41 (we tend to use 1k–2k)

Performance:

XNA
	Dev machine:		250fps, 
				Update 	2.0–2.2ms, 
				Draw 	1.0ms, 
				Very steady
						
	Lenovo Horizon i5:	108–116fps, 
				Update 	3.8–4.6ms, 
				Draw 	3.8–4.6ms, 
				Steady
WinStore
	Dev machine: 		62.5fps, 
				Update	3ms, 
				Draw 	1.0ms, 
				Very steady

	Lenovo Horizon i5: 	36–56fps, 
				Update 	4.0–12.8ms, 
				Draw 	1.8–2.4ms, 
				Highly erratic

Download the Test Solution here:

Dropbox - Error

CPU Load Profiles of our game (technically a different project, but almost certainly same issue):

Thanks for taking a look, it’s much appreciated.

[Tom]

This is great… i’ll be looking at it over this weekend.

[AdamHill]

Thanks, Tom. Let me know if we can help at all, e.g. maybe try and cut the project down even more?

[Tom]

@AdamHill

Let me know if we can help at all

Nope… i’m good. Working on it.