locked
Windows Modern App Suspend callback in C++ with no XAML

    Question

  • Hi there,

    We have a game use only DirectX 11 with no XAML layer. We've started receiving reports of failing the WACK test due to it not detecting the suspend event. Looking into this, we're not actually doing anything on suspend and we don't need to do any saving, so we don't understand why it's not suspending immediately. Is there anything that we can do about this? The C++ samples only show how to catch a suspend event using XAML, is there any other way to catch it in C++? What does Windows exactly do when there is no suspend event that takes so long?

    Thanks,

    David Goemans

    Friday, February 1, 2013 10:10 AM

Answers

All replies

  • What you're looking for is the Windows::ApplicationModel::Core::CoreApplication::Suspending event - http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.core.coreapplication.suspending.aspx . You probably also want to hook up the Resuming static event in that class as well.

    You can see this in use in the DirectX Shooting Game sample - http://code.msdn.microsoft.com/windowsapps/Metro-style-DirectX-7c64aa8d (specifically in DirectXApp::Initialize). Note that there's a XAML version of that sample as well, which isn't what you'd be looking for; the link above points to the right one. You may want to look through it carefully for other events that it hooks to (e.g. the CoreApplicationView's Activated event, the various CoreWindow events, LogicalDpiChanged, DisplayContentsInvalidated, etc.) to make sure you are handling all of those and are doing so properly.


    XNA/DirectX MVP | Website | Blog | @mikebmcl

    • Proposed as answer by MikeBMcL Sunday, February 3, 2013 2:26 PM
    • Marked as answer by Jesse JiangModerator Wednesday, February 6, 2013 2:11 AM
    Saturday, February 2, 2013 8:02 AM
  • Mike,

    Thanks for the response. Good to see there is a non-Xaml version. We've looked for it before but never found it.

    We've implemented both the suspend and resume events, but we're still noticing a considerable delay between going to the desktop ( Win + D ) and the suspend event being called. What does Windows do that takes so long?

    Thanks,

    David

    ( Note I had to reply to my own post as I don't see a reply button on yours and this is the only way I can respond )
    Wednesday, February 6, 2013 9:58 AM
  • (There should be a "Reply" link at the bottom of each post; I see it in IE10 but I don't know what browser you might be using so maybe there's a browser that it's not visible in for some reason.)

    I have no idea why it takes time to suspend. I suspect that it's because suspending an app is likely to take system resources (e.g. saving data to disk, paging out memory, etc.) which costs battery life such that if the user switches back right away (maybe they switched away by accident or just to glance at the notifications on Start Screen tiles) then they'd end up waiting the up to 2 seconds for suspend and then the up to 5 seconds for resume as well as losing a small bit of battery life on an unplugged device. Also, the first task for Windows when it switches away from something would be to handle anything associated with switching to the thing (e.g. the Desktop) that it is going to. So it'd want to do that first, then wait a short bit to ensure that the user doesn't switch right back, and only then go ahead with a suspend.

    That's just guess work on my part though. Windows will schedule a suspend when needed sometime after the user switches away (unless the user instantly switched to task manager and killed the app; if it hadn't already commenced a suspend then I don't know that it would run one in that weird edge case but if suspend had started then I expect it would give it the 2 seconds it's supposed to have to finish suspending before terminating it but again that's just a guess).

    Suspend should commence within a reasonable amount of time (I'd say probably 5 to 10 seconds after switching away); if you are seeing times significantly longer than that then post a new question thread about it and hopefully someone who knows more will be able to provide some insight into what is going on and some suggestions on thing that might be going wrong in your app. I've never tested what'd happen if a long-running synchronous call was occurring when the user switched away from an app, for example; possibly that would stall a suspend operation. As a suggestion, try creating a retail build and running the game through WACK to see if it passes (or if it fails but only because you haven't switched away from the default icons yet or something else non-code related). That might help identify potential issues as well.


    XNA/DirectX MVP | Website | Blog | @mikebmcl

    Wednesday, February 6, 2013 10:20 AM
  • (Oddly I can reply to this one, just not the 'Answer')

    Thanks for the super fast response! It's good to know that the suspend only kicks in 5 to 10 seconds after switching away, because it was suggested that time was the actual suspend time for the app ( something that doesn't make sense to us ). Unfortunately, we can't repro the WACK failures on any of our hardware, so we're actually not sure if catching the event makes any difference. I guess we'll just have to hand a new build onto a QA team :)

    Thanks,

    David

    Wednesday, February 6, 2013 10:32 AM
  • You should be fine. If possible, try to run it on an Intel Atom-based machine (or similar) with a mechanical (i.e. non-SSD) hard drive since HDD I/O times when combined with a processor designed for low battery consumption can change those times quite a bit. An older netbook (provided it has a screen that's at least 1024x768) should fit the bill. Something else to consider is saving out the start and completion times (or even using OutputDebugString to write out the times) and then displaying them the next time you start up (just as a debugging measure).

    XNA/DirectX MVP | Website | Blog | @mikebmcl

    Wednesday, February 6, 2013 10:47 AM