[StoreApps/XAML] Run Game Loop and Input on a seperate Thread

[nkast]

Fixes mouse, keyboard lag [UAP] touch, rotation lag & freeze (WP8.1).
#4897, #5300, #3948, #3589, #3316, #4105(?).

This probably still has a ton of bugs. It's hard to tell unless you review every line of MG codebase and run extensive tests. Unfortunetly, that's the nature of thread syncronization. I'd prefer to wait until after 3.6 (and a possible 3.6.1 service update) for this PR.

On the other hand #5352 is more predictable and solves 99% of the issues with just a couple of lines.

[nkast]

@Danthekilla, @MartinZikmund, @VitezslavImrysek @jakepoz,
will you give this a run?

[jakepoz]

Hey nkast, will do a check here ASAP. We are also working on our own solution with @roponator so we will compare notes.

@roponator is making a fuzz tester that will run some live games overnight with very intense workloads. We want to use that we want to use as a way to verify that the multi-threading is reliable.

We are hoping to get a fix for this issue into 3.6. I feel it's a decent time to ask developers to adjust their code to Dispatch UI thread calls. Also, publishing a UWP app without this fix is just asking for lots of user complaints as we have unfortunately found out the hard way.

[Jjagg]

We are hoping to get a fix for this issue into 3.6.

Probably will have to be for 3.6.1 as 3.6 will be released this week.

[jakepoz]

@Jjagg Got it, I didn't know it was coming so soon. Either way, we are testing this fix ASAP.

@nkast Just gave this a quick test run and it seems to be working. We are going to build some of our games against this PR and run them overnight in a fuzz tester. It has been really good finding low frequency deadlocks and similar threading problems.

[tomspilman]

@jakepoz - We should look at your solution as well... is it similar to this?

We will get this issue solved and shipped in a 3.6.1 release.

[jakepoz]

Yeah, it is similar. Instead of saving the state of each event that comes in off the main thread, and then "replaying" it like this PR does, @roponator was pausing the game loop, letting the event occur, and then resuming the game loop.

@nkast solution looks more robust, we are doing some overnight fuzz testing and will know the results shortly.

[roponator]

I think @nkast 's solution is better than mine since it doesn't lock the main loop since it stores just the last window event. I thought that may be a problem (eg if old window events would be discarded) but the ~8 hour overnight fuzz testing (all possible window change events like minimize, maximize, resize, screen rotation and then game input simulation) worked 100% fine on nkasts version so his should be used instead :)

[jakepoz]

Sweet, we will do a live deployment on a small game of ours and see what the Health reports look like after a week. That should make good use of the time between now and getting this into 3.6.1 :)

[jakepoz]

Ok, we have 2 live games updated with this PR. Will report back in a few days on the results.

[KonajuGames]

Thanks for the testing, Jake. It is very helpful.

[VitezslavImrysek]

I am going to check tomorrow and report back the results :).

[nkast]

Thanks everyone for testing this.

@roponator

the ~8 hour overnight fuzz testing (all possible window change events like minimize, maximize, resize, screen rotation and then game input simulation)

That sounds interesting! +1

[jakepoz]

Hey,

Everything looks great on the Windows 10 desktop side. But there is a problem on Windows Phone 10 where it will crash on the first button you press:

Exception thrown: 'System.Runtime.InteropServices.COMException' in MonoGame.Framework.dll

WinRT information: Windows.Graphics.Display: GetForCurrentView must be called on a thread that is associated with a CoreWindow.

Additional information: Element not found.

That happens on the following line in InputEvents.cs

  private void PointerPressed(PointerPoint pointerPoint, UIElement target, Pointer pointer)
        {
            // To convert from DIPs (device independent pixels) to screen resolution pixels.
            var dipFactor = DisplayProperties.LogicalDpi / 96.0f;

[jakepoz]

@nkast Sent a Pull Request with our fix for the Windows Phone issue:

nkast#8

[nkast]

Thanks @jakepoz
I'll test it soon.

[nkast]

@jakepoz
The strange thing is that only WP10 had that issue. I tested the fix with WP8.1, W8.1, and W10 too.
Everything seems fine. In addition we removed the obsolete DisplayProperties and the division by 96.0 on each event. Thanks.

[jakepoz]

@nkast Kk, just confirmed the health reports and everything is good. We have this deployed to a few thousand active users without issue. Can we merge this in now?

We also have this bounty open on this issue that we can finally close out:
https://www.bountysource.com/issues/7309032-wp8-1-multitouch-slowdown

[VitezslavImrysek]

I tested this PR and the input lag seems to be fixed. I haven't noticed any problems so far.
Good job, thanks for fixing this!

[KonajuGames]

Thanks for all the work on this. Great to have a large test userbase. I'm happy to merge this now.

[nkast]

@KonajuGames ,
Can we close the related issues?
#4897, #5300, #3948, #3589, #3316, #4105.

(It's required to claim the bounty on #3316)

[tomspilman]

@nkast - Done!