[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    issue with DPI awareness
From:       Kimball Thurston <kdt3rd () gmail ! com>
Date:       2018-12-30 5:43:14
Message-ID: CAHXn2BCOVnpjWNfs=uuNhpargCSqtaANJuMKPZV3N8hz39gbsA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


All -

I'm attempting to fix my own bug report (
https://bugs.winehq.org/show_bug.cgi?id=45917), but need someone who knows
this code better to comment. If one sets the process-level DPI awareness to
unaware (DPI_AWARENESS_UNAWARE) (which is what battle.net does), then the
mouse selection (at least) ends up not working, resulting in a scaled /
shifted mouse selection (when you click on something, an item up and to the
left will be selected based on the distance from top left, and scale of
dpi) - it's easiest to see if the window is exactly in the upper left
corner of the screen.

An easy way to see this is set your HCU\Control Panel\Desktop\LogPixels to
161 (the dpi of my 4k monitor), I also have my windows version at 10, then
add

SetProcessDpiAwarenessContext( DPI_AWARENESS_CONTEXT_UNAWARE );

as the first line of WinMain for something (I am using
programs/regedit/main.c because I know it has child windows, although I
don't believe that is the issue currently, but started w/ that idea). I
presume the same would happen if the dpi awareness were in the app manifest.

When I look at the coordinates of the mouse as they flow through
process_mouse_message in dlls/user32/message.c, the WINPOS_WindowFromPoint
calls find an hwnd, and then the modification point_phys_to_win_dpi seems
plausible. However, the hittest value from WindowFromPoint does not work
(returns HTNOWHERE when it shouldn't). And then the ScreenToClient that
happens when the mouse is in the client area overly shifts the mouse
position before it is put into the lParam of the event. A common theme of
both the hittest and the ScreenToClient is the client_rect. Printing out
the values, it appears like the client_rect is in monitor_dpi instead of
window dpi, at least for the application top level window, or there's a
disconnect because there's a boundary where the desktop window is in
per_monitor, but the app is in unaware.

At this point, if someone could take a look, and advise me whether the
various window rects should be in monitor dpi or in window dpi, then I can
try to track down what needs to change where to make that work, unless by
reading the above it's obvious to someone who knows this code better than
I? I don't have a windows machine to run tests on to validate, but am happy
to try to help write the code if someone can suggest a good type of
conformance test.

thank you in advance,
Kimball

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">All -<div><br></div><div>I&#39;m attempting to fix my \
own bug report (<a href="https://bugs.winehq.org/show_bug.cgi?id=45917">https://bugs.winehq.org/show_bug.cgi?id=45917</a>), \
but need someone who knows this code better to comment. If one sets the process-level \
DPI awareness to unaware (DPI_AWARENESS_UNAWARE) (which is what <a \
href="http://battle.net">battle.net</a> does), then the mouse selection (at least) \
ends up not working, resulting in a scaled / shifted mouse selection (when you click \
on something, an item up and to the left will be selected based on the distance from \
top left, and scale of dpi) - it&#39;s easiest to see if the window is exactly in the \
upper left corner of the screen.</div><div><br></div><div>An easy way to see this is \
set your HCU\Control Panel\Desktop\LogPixels to 161 (the dpi of my 4k monitor), I \
also have my windows version at 10, then \
add</div><div><br></div><div>SetProcessDpiAwarenessContext( \
DPI_AWARENESS_CONTEXT_UNAWARE );</div><div><br></div><div>as the first line of \
WinMain for something (I am using programs/regedit/main.c because I know it has child \
windows, although I don&#39;t believe that is the issue currently, but started w/ \
that idea). I presume the same would happen if the dpi awareness were in the app \
manifest.</div><div><br></div><div>When I look at the coordinates of the mouse as \
they flow through process_mouse_message in dlls/user32/message.c, the \
WINPOS_WindowFromPoint calls find an hwnd, and then the modification \
point_phys_to_win_dpi seems plausible. However, the hittest value from \
WindowFromPoint does not work (returns HTNOWHERE when it shouldn&#39;t). And then the \
ScreenToClient that happens when the mouse is in the client area overly shifts the \
mouse position before it is put into the lParam of the event. A common theme of both \
the hittest and the ScreenToClient is the client_rect. Printing out the values, it \
appears like the client_rect is in monitor_dpi instead of window dpi, at least for \
the application top level window, or there&#39;s a disconnect because there&#39;s a \
boundary where the desktop window is in per_monitor, but the app is in \
unaware.</div><div><br></div><div>At this point, if someone could take a look, and \
advise me whether the various window rects should be in monitor dpi or in window dpi, \
then I can try to track down what needs to change where to make that work, unless by \
reading the above it&#39;s obvious to someone who knows this code better than I? I \
don&#39;t have a windows machine to run tests on to validate, but am happy to try to \
help write the code if someone can suggest a good type of conformance \
test.</div><div><br></div><div>thank you in \
advance,<br></div><div>Kimball</div></div></div>


[Attachment #6 (text/plain)]




[prev in list] [next in list] [prev in thread] [next in thread]