Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PresentMon: Option to choose monitor or save last position for both itself and windowed overlay? #158

Open
velocity7 opened this issue Aug 27, 2023 · 3 comments
Assignees
Labels
bug PresentMon-Overlay Relates to the overlay/hud

Comments

@velocity7
Copy link

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.

@velocity7
Copy link
Author

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:

image

@planetchili
Copy link
Collaborator

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.

@planetchili
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug PresentMon-Overlay Relates to the overlay/hud
Projects
None yet
Development

No branches or pull requests

4 participants