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

Jump to bottom

Some apps refuse to return physical coordinates for high DPI settings when NVDA is DPI aware #3875

Closed
nvaccessAuto opened this issue Feb 11, 2014 · 9 comments · Fixed by #13254
Closed

Some apps refuse to return physical coordinates for high DPI settings when NVDA is DPI aware #3875

nvaccessAuto opened this issue Feb 11, 2014 · 9 comments · Fixed by #13254
Labels
bug/regression bug displayScaling Display scaling and DPI awareness p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Milestone
2022.4

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2014-02-11 04:52
(Spun off ticket:3758#comment:7.)
Some DPI unaware apps such as Steam and Demul give us logical coordinates when we call LogicalToPhysicalPointForPerMonitorDPI (and probably the reverse as well). MSDN says that these functions are supposed to give physical coordinates regardless of DPI awareness, so this seems like a Windows bug. Strangely, the function works as expected when we aren't DPI aware, which is pretty silly.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2015-01-23 02:44
I've seen several other instances where this coordinate translation fails; e.g. items in SysListView32 controls. I'm starting to think we should just perform the conversion ourselves. That is, if the app isn't DPI aware, we assume it is 96 DPI and scale to the system DPI. The only problem is that you can only query the DPI awareness of a remote process in Windows 8.1 and later. I'm hoping this stuff just behaves as expected in earlier versions.

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2015-07-22 05:19
To get the DPI of the screen:

screen = ctypes.windll.user32.GetDC(None)
x = ctypes.windll.gdi32.GetDeviceCaps(s, 88) # LOGPIXELSX
y = ctypes.windll.gdi32.GetDeviceCaps(s, 90) # LOGPIXELSX
ctypes.windll.user32.ReleaseDC(None, screen)

@nvaccessAuto nvaccessAuto added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jul 5, 2016
@Adriani90
Copy link
Collaborator

@jcsteh any updates on this issue? Was there any further work on it so far?
cc: @michaelDCurran

@jcsteh
Copy link
Contributor

jcsteh commented Dec 24, 2018

No; I never did any work on it beyond my investigations above.

@LeonarddeR LeonarddeR added the displayScaling Display scaling and DPI awareness label May 2, 2019
@seanbudd seanbudd mentioned this issue Jul 18, 2022
Merged
34 tasks
@seanbudd
Copy link
Member

Is this still an issue? I'm struggling to determine the steps to reproduce this

@jcsteh
Copy link
Contributor

jcsteh commented Aug 17, 2022

I'm not sure. I'd say you could test it as follows:

  1. Ensure you're on a high DPI system.
  2. Get either Steam or Demul. NO idea where to get them from.
  3. Use screen review and try to route the mouse to a particular piece of text on screen.

Assuming these apps are still DPI unaware (and honestly, there's no guarantee of that), if the bug exists, the mouse will get routed to the wrong place.

@seanbudd
Copy link
Member

Thanks, not knowing step 3 is where I was stuck

@seanbudd
Copy link
Member

seanbudd commented Aug 17, 2022 •
edited

Interesting, using the latest alpha and steam the mouse routing appears to work correctly, but with visual highlighting the frames are way off.

@seanbudd
Copy link
Member

This will be fixed by #13254

@seanbudd seanbudd added the triaged Has been triaged, issue is waiting for implementation. label Aug 18, 2022
seanbudd pushed a commit that referenced this issue Aug 30, 2022
@VeselovAlex
Use modern DPI awareness settings (#13254)
28b4756 
Fixes #13370
Fixes #6722
Fixes #3875
Fixes #12070
Fixes #7083
Fixes #7915
Likely fixes #9531, otherwise close as stale/can't reproduce

### Summary of the issue:
When DPI for a monitor is not set to 100%, or when using multiple monitors with different DPI settings,
NVDA would:

- misplace highlight frames
- have inaccurate mouse tracking
- have inaccurate touch screen interaction

NVDA currently sets the DPI awareness via a Windows API call introduced in Windows Vista.
It is recommended to set DPI through the app manifest, rather than Windows API calls where possible.

Newer settings for DPI awareness have been introduced since Windows Vista.
Windows 8 introduced multiple monitor DPI awareness.
Windows 10 introduced a richer version of multiple monitor DPI awareness.

### Description of how this pull request fixes the issue:
Background docs: https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows#per-monitor-and-per-monitor-v2-dpi-awareness

When running as an executable, NVDA sets DPI awareness via the app manifest.
When running through source, NVDA sets DPI awareness via Windows API calls.
The most modern method available is used to set DPI awareness.

- For Windows 7, DPI awareness is unlikely to improve. There may be fixes from setting it via the app manifest instead of via Windows API calls.
- For Windows 8 and newer, NVDA has per monitor DPI awareness
- For Windows 10 1703 and newer, NVDA has [advanced per monitor DPI awareness](https://docs.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context), including:
  - Child window DPI change notifications
  - Scaling of non-client area - All windows will automatically have their non-client area drawn in a DPI sensitive fashion. Calls to [EnableNonClientDpiScaling](https://docs.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-enablenonclientdpiscaling) are unnecessary.
  - Scaling of Win32 menus - All NTUSER menus created in Per Monitor v2 contexts will be scaling in a per-monitor fashion.
  - Dialog Scaling - Win32 dialogs created in Per Monitor v2 contexts will automatically respond to DPI changes.
  - Improved scaling of comctl32 controls - Various comctl32 controls have improved DPI scaling behavior in Per Monitor v2 contexts.
  - Improved theming behavior - UxTheme handles opened in the context of a Per Monitor v2 window will operate in terms of the DPI associated with that window.
@nvaccessAuto nvaccessAuto added this to the 2022.4 milestone Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug/regression bug displayScaling Display scaling and DPI awareness p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Milestone
2022.4
Development

Successfully merging a pull request may close this issue.

Use modern DPI awareness settings VeselovAlex/nvda
5 participants
@LeonarddeR @jcsteh @seanbudd @nvaccessAuto @Adriani90