PresentMon
PresentMon copied to clipboard
PresentMon: Option to choose monitor or save last position for both itself and windowed overlay?
I'm trying to monitor a game that uses exclusive fullscreen, but would like the monitoring metrics to appear on another monitor. However, anytime I regain focus with the game, PresentMon decides to generate a new windowed overlay on the same monitor as the game that's running. This is fine for other games, but for games running exclusive fullscreen, it causes the game to immediately lose focus and auto-minimize, and the entire process starts again.
I'd like an option to do something like, choose which monitor the windowed overlay would initially start at, just to avoid this issue.
Hello, wanted to update this issue.
I went ahead and pulled the code from the GitHub and made some changes to actually allow this to happen; in particular, "PresentMon Data Display" window in my local copy will now follow the "Intel PresentMon" window position when created. It's a bit of a hack but will do the job for now. If anyone wants to try this, they can edit Overlay.cpp as follows:
Thanks for your feedback on Intel PresentMon. The issue you describe is one that has been reported to us internally as well. It seems not to affect all fullscreen exclusive games, but only certain titles (for example, Tomb Raider 2013 in fullscreen exclusive mode exhibits the bug you describe, but Shadow of the Tomb Raider in fullscreen exclusive does not). We are working on a fix and hope to make it into the next release.
The issue of the spawn location of the independent metric window is a separate concern that we are also considering. Eventually we will want to store the window's last known location in the user preferences and use that location when spawning a new independent metric window.
Just an update to this issue, I have identified the root cause and fixed it, so now even if the metrics window is on the same monitor as the target, it should not interfere with the game. And since the metrics window is not being respawned, it will stay where it is positioned.
In case you're interested, the cause is rooted in some code we have to detect when a process kills/spawns new windows. It seems that Tomb Raider 2013 was doing this, and probably other apps as well. It is essential with the overlay that we track such events and make sure the overlay window is "targeting" and "attached to" the appropriate hWnd. For an independent metrics window this is not needed, and turns out to have been actually detrimental, so we have added extra checks to disable the behavior when the using the independent metrics window.
I have also taken inspiration from your "hack" and made the default behavior for when the metrics window does spawn for the first time. Thanks again for your contribution.