Skip to content

make application per monitor DPI aware#29

Open
guyyst wants to merge 1 commit intoVerpous:masterfrom
guyyst:master
Open

make application per monitor DPI aware#29
guyyst wants to merge 1 commit intoVerpous:masterfrom
guyyst:master

Conversation

@guyyst
Copy link

@guyyst guyyst commented Oct 14, 2025

I had issues with the context menu appearing in weird positions when using multiple monitors with different resolutions. This fixes that, and also has the added benefit of making the context menu non-blurry on 4k monitors.

@Verpous
Copy link
Owner

Verpous commented Oct 16, 2025

Never thought someone would actually open a PR on my humble little repository. Anyway thanks for bringing the topic to my attention. I've read a bit about it and I'm not sure PerMonitorV2 is the right way to go. It sounds like this is a mode for programs that want to manually handle DPI changes; it doesn't sound like a mode you just set and everything "works" without adjusting your code to actually do something with the user's DPI.

Currently my code is truly DPI unaware, and that is something I could improve. I'll write it down for myself to do, so watch out for a possible future update. For now it would be really helpful if you could include some screenshots or even videoclips to help me understand what the issue even is.

I'm very flattered you went and worked on this PR but in its current state I don't think I'll merge it, and I think I'd rather make code changes myself than ask you go to and improve the PR further. For now since you've gone through all this trouble, I'm guessing you've figured out how to compile the program yourself so you can just use your own personal version. Cheers!

@guyyst
Copy link
Author

guyyst commented Oct 16, 2025

I had originally written a simple issue about this, but then I couldn't let it go without trying some stuff myself, so this PR was mostly intended to bring the problem to light. As you guessed I compiled it for myself and am just using that version (Thanks for the instructions btw, I hadn't used MSYS2 in forever :p).

The issue actually had more info regarding the symptoms and replication of the "bug". I should've included that in the PR as well from the get-go, but here you go:


My Windows monitor setup looks lke this, with the left (main) monitor at 4K and the right at 2560x1440:
2025-10-14__23-20-34

With this, the AlwaysShadow icon lives on the taskbar in the bottom right of the 4K monitor, but clicking the icon will show the context menu in the bottom left of the right monitor, like this:
2025-10-14__23-19-29

Although this behaviour isn't 100% consistent. When I first compiled the master branch without any changes, the menu suddenly appeared in the very bottom right of the 4K monitor. Still not near where I clicked the icon though. I'm not sure what causes it to eventually end up on the other monitor. Maybe Windows sleep? idk.

Forcing my left monitor down to 2560x1440 makes this issue go away completely. Which likely also means that this is easily reproducible by anyone with multiple monitors, even if they're all the same resolution. Just force one of them to a different res in Windows.


When I first looked through the code I was messing around with the TRAY_ICON_CALLBACK, because I assumed the bug must be somewhere in the coordinate calculation/sourcing. But I banged my head against the wall for like an hour trying to get 3 things to have proper positioning at once: Opening the menu with a left click, right click and by navigating to the icon with the keyboard and hitting enter.

You can kinda cheat the clicking part by just reading the mouse position, but that was hacky as hell and wouldn't support keyboards. So I gave up and found some places saying that just switching to marking the application as PerMonitorV2 DPI aware fixes tray icon menu positioning. I tested changing both my Windows scaling and display resolution with the program running in PerMonitorV2 mode and the position remained correct throughout. Since AlwaysShadow has no other UI aside from this native context menu (iirc), I figured there wasn't anything else to make DPI aware.

I didn't really expect you to merge it to be honest though :D — But I figured a runnable PR example is just as good a place for discussion as an issue.

And thanks for making this thing. It saved by bacon more than a few times now after Sleep/Teams/etc. stopped Shadow Play :D

@guyyst
Copy link
Author

guyyst commented Oct 16, 2025

Yeah this is what the current release version looks like for me right after launching it:

2025-10-17__00-06-12

I can't figure out what moves it to the second monitor, but that's where I've had it pop up every time I tried to access it for the last couple of weeks. Sleep doesn't move it over either ¯\_(ツ)_/¯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants