Use actual value of display scale factor from GetMonitorScaleFactor().

Use actual value of display scale factor from GetMonitorScaleFactor().

BUG=665965

[Andrey Kraynov, 2016-11-16 18:26:22]

Description was changed from

==========
Use actual value of display scale factor from GetMonitorScaleFactor().

BUG=
==========

to

==========
Use actual value of display scale factor from GetMonitorScaleFactor().

BUG=665965
==========

[Andrey Kraynov, 2016-11-16 18:33:46]

iceman@yandex-team.ru changed reviewers:
+ sadrul@chromium.org

[Andrey Kraynov, 2016-11-16 18:33:47]

Hi!

I tried to explain the issue in the
https://bugs.chromium.org/p/chromium/issues/detail?id=665965

This is my attempt to fix the problem, but it is more like a proof of concept
with additional logging that should be removed later.
Could you take a look at this and give me an advice?
Thanks!

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.cc
File ui/display/win/screen_win.cc (right):

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.c...
ui/display/win/screen_win.cc:445: return GetMonitorScaleFactor(
Another possible and simple way to fix this issue is to handle WM_DPICHANGED in
ScreenWin::OnWndProc and update displays.
But I failed to get it there. Should ScreenWin::OnWndProc() function receive
WM_DPICHANGED event?

[sadrul, 2016-11-16 20:38:17]

sadrul@chromium.org changed reviewers:
+ robliao@chromium.org

[sadrul, 2016-11-16 20:38:18]

+robliao@

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.cc
File ui/display/win/screen_win.cc (right):

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.c...
ui/display/win/screen_win.cc:445: return GetMonitorScaleFactor(
On 2016/11/16 18:33:47, Andrey Kraynov wrote:
> Another possible and simple way to fix this issue is to handle WM_DPICHANGED
in
> ScreenWin::OnWndProc and update displays.
> But I failed to get it there. Should ScreenWin::OnWndProc() function receive
> WM_DPICHANGED event?

I think that would make sense, yeah. Is that possible to do? Looks like it
currently processes only WM_DISPLAYCHAGE, but WM_DPICHANGED would be something
it should process too.

[robliao, 2016-11-16 20:56:17]

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.cc
File ui/display/win/screen_win.cc (right):

https://codereview.chromium.org/2510793002/diff/1/ui/display/win/screen_win.c...
ui/display/win/screen_win.cc:445: return GetMonitorScaleFactor(
On 2016/11/16 20:38:17, sadrul wrote:
> On 2016/11/16 18:33:47, Andrey Kraynov wrote:
> > Another possible and simple way to fix this issue is to handle WM_DPICHANGED
> in
> > ScreenWin::OnWndProc and update displays.
> > But I failed to get it there. Should ScreenWin::OnWndProc() function receive
> > WM_DPICHANGED event?
> 
> I think that would make sense, yeah. Is that possible to do? Looks like it
> currently processes only WM_DISPLAYCHAGE, but WM_DPICHANGED would be something
> it should process too.

WM_DPICHANGED is fired when an HWND is associated with a different DPI. This is
principally for per-monitor DPI window changes when you drag a window from one
screen to the other but can happen when you change the DPI of the HWND's current
display.

The SingletonHwnd is bound to the primary display at (0,0) with (0,0) size. As a
result, it will only get WM_DPICHANGED for the primary display. If change the
DPI on a secondary display, you may not receive a WM_DPICHANGED.

Taking a step back, I'm seeing WM_DISPLAYCHANGED fired first and then
WM_DPICHANGED.
This ordering is important from Windows's point for view for the reasons
described in the bug, applications that are doing display tracking like we are
need to update their metrics first before firing the WM_DPICHANGED.

I'll loop this discussion into the bug, but the main question I have is how does
one get WM_DPICHANGED to fire before WM_DISPLAYCHANGED?

[Andrey Kraynov, 2016-11-23 20:34:01]

On 2016/11/16 20:56:17, robliao wrote:

> I'll loop this discussion into the bug, but the main question I have is how
does
> one get WM_DPICHANGED to fire before WM_DISPLAYCHANGED?

I tried to describe  my setup in the bug.
Could you take a look please?
May the presence of the second physical monitor be the reason for messages
reordering?

[robliao, 2016-11-23 22:56:21]

On 2016/11/23 20:34:01, Andrey Kraynov wrote:
> On 2016/11/16 20:56:17, robliao wrote:
> 
> > I'll loop this discussion into the bug, but the main question I have is how
> does
> > one get WM_DPICHANGED to fire before WM_DISPLAYCHANGED?
> 
> I tried to describe  my setup in the bug.
> Could you take a look please?
> May the presence of the second physical monitor be the reason for messages
> reordering?

I can attempt to repro again next Tuesday at the US will be on holiday the next
two days.

My setup is also with two monitors. Dragging the window from one monitor to the
next of a differing DPI will result in just a WM_DPICHANGED.
Changing the DPI will result in a WM_DISPLAYCHANGED and then a WM_DPICHANGED.

[Andrey Kraynov, 2016-11-24 14:06:07]

On 2016/11/23 22:56:21, robliao wrote:

> I can attempt to repro again next Tuesday at the US will be on holiday the
next
> two days.

That would be great, thank you.