19 Agustus 2012 15:40
My Metro app downloads realtime data and displays it with D3D. It creates fairly large textures (~one megapixel) for that data and caches it for animating. I'm confused about how my app should behave when suspended:
1. If animating the data when suspending, should it automatically stop animating when suspending?
2. Should it delete those cached textures?
3. Should it also release the D3D device?
So far I've been focussed on getting and displaying the data but now need to look into the app lifecycle behavior. I'm not sure how the lifecycle applies to my realtime app. In my existing desktop apps I clean up everything on exit (clean debug D3D exit). For Metro, it seems like I should only do item #1 above and let Windows clean up the rest of the mess if it decides to terminate the app. If I do a significant amount of cleanup on suspension then I would need to do a bunch of reconstruction at resume time, even if the user only momentarily switched away from my app. Obviously, if the app is suspended for a significant amount of time, it would need to invalidate alot of its realtime data since it would be stale ... but I see that as a completely separate issue.
What are the official MSFT guidelines on suspension of a D3D Metro app? I've read the regular Guidelines page but it doesn't say anything about D3D resources.
21 Agustus 2012 0:28Moderator
Conventional wisdom states that you follow the architecture that the Microsoft D3D samples suggest. In these samples the gameplay is paused during suspension, the current state of the game is saved, the cursor is returned to normal and the audio engine is stopped. In these samples pausing the game stops the game timer. Cleanup on termination is handled by the framework.
I hope this helps,
Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/