And, I didn't attach the .png...

Deleted: min-max-close.png 20.2 KB

	min-max-close.png 20.2 KB View Download

Also noted in the discussion, RDP may have been involved.

Just shutdown and reopen and it happens straight away: correct on 150, large on 100.

Fine on Stable 53 fwiw, but presumably that's just because we're not PROCESS_PER_MONITOR_DPI_AWARE there yet.

This is happening on Version 54.0.2840.16
Monitor 1 at 225% scaling, monitor 2 at 100% scaling; Chrome on monitor 2.

54.0.2840.27 still has the bug

I'm not positive, but this may be related to my new bug in the stable version 53 (yikes, stable version).

Windows 10 high DPI scaling flag is suddenly reversed in sense
https://bugs.chromium.org/p/chromium/issues/detail?id=648082


I'm seeing dozens of complaints in forums.  I believe that everyone using Windows 10 display scaling has had their scaling toggled on/off for Chrome, to exactly the opposite of the setting they were using.

Re: 8
No it is not related in my case. I just tried enabling that checkbox and it had no effect on the scaling issues in 54.

OK, #9, thanks for ruling out the connection for your case.  I'll leave the comment in case it makes a useful connection for someone else later.  Cheers.

FWIW, I just installed clean Win10 on a new computer that was imaged with Win10 RTM, and it wasn't happening. I then updated to Anniversary and it seems to have started again.

Interesting. I wonder if it's a Win10 Anniversary regression. The fact that it happens in other apps strongly suggests that.

This is happening because as a part of Chrome's high-DPI work, Chrome now tells Windows that it is per-monitor DPI aware (instead of system DPI aware).

Previously (as a system DPI aware-only app), Windows' DWM did bitmap scaling of the *entire* window, including non-client things like the min/max/close buttons and the system menu (alt+space).

Once an app declares itself per-monitor DPI aware, DWM stops doing bitmap scaling.  An unfortunate side effect of this is that Windows ALSO does not automatically scale the caption buttons and system menu to render at the appropriate pixel size for the current display, resulting in the silly large buttons you see in recent Chrome versions.

Even more absurd is that until very recently, there was actually no way to get Windows to scale the non-client area of a per-monitor DPI-aware window.  In other words, you were forced to draw the standard window controls yourself if you want them to show up correctly on low-DPI displays. (WTF?!?  see http://stackoverflow.com/q/31781767/201952)

The good news is that with the recently (August) released Anniversary Update (v1607) adds a new API that enables automatic scaling of the non-client area of a window:

    EnableNonClientDpiScaling(hWnd);

> You can only call EnableNonClientDpiScaling for top-level windows that have a DPI_AWARENESS_CONTEXT of DPI_AWARENESS_PER_MONITOR_AWARE. If you call this method for any other window, it will fail and return a value of zero.
>
> Non-client scaling for a window is not enabled by default, you must call this API to enable it. Once you do, there is no way to disable it. Enabling non-client scaling means that all the areas drawn by the system for the window will automatically scale in response to DPI changes on the window. That includes areas like the caption bar, the scrollbars, and the menu bar. You want to call EnableNonClientDpiScaling when you want the operating system to be responsible for rendering these areas automatically at the correct size based on the API of the monitor.
(https://msdn.microsoft.com/en-us/library/windows/desktop/mt748621.aspx)

To see this in action, Notepad is actually a good example.  Prior to the AU, Notepad was only system DPI aware, so DWM did bitmap scaling of Notepad on low-DPI screens (you can see that text was rendered slightly blurry).  After the AU, Notepad is per-monitor DPI aware and calls EnableNonClientDpiScaling, so everything in the titlebar looks correct and text renders natively at the current display's resolution.

There's a good MS blog post that discusses DPI-related changes in the AU here: https://blogs.technet.microsoft.com/askcore/2016/08/16/display-scaling-changes-for-the-windows-10-anniversary-update/

---

All of that to say: to fix this, Chrome just needs to call EnableNonClientDpiScaling(hWnd) when it creates new windows.

Thanks for the info! It'd be great to get this fixed.

No problem.  Remember to be careful with EnableNonClientDpiScaling -- it simply did not exist in RTM Windows 10 (or previous versions), so make sure the function exists before calling!

Thanks for the info indeed. We knew about EnableNonClientDpiScaling, but as you said, we had to wait for the Win10 Anniversary Edition to get it. We actually use a different method of achieving the same thing (which is why we're able to scale the rest of the frame). We will be switching to EnableNonClientDpiScaling, but we have to keep the old way for Win10 non-anniversary users.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b297db871b54cd58c32c96897a7a59af295ba796

commit b297db871b54cd58c32c96897a7a59af295ba796
Author: robliao <robliao@chromium.org>
Date: Wed Dec 14 23:36:17 2016

Call EnableNonClientDpiScaling

Windows versions after 10.0.14393.0 have EnableNonClientDpiScaling,
performing the same function as EnableChildWindowDpiMessage for us.

EnableChildWindowDpiMessage was also removed in 10.0.14393.0 if not
earlier.

This change also allows delegates to handle the WM_NCCREATE message,
required to properly call EnableNonClientDpiScaling.

BUG= 642956 ,  658787 

Review-Url: https://codereview.chromium.org/2574933002
Cr-Commit-Position: refs/heads/master@{#438674}

[modify] https://crrev.com/b297db871b54cd58c32c96897a7a59af295ba796/ui/events/win/event_utils_win_unittest.cc
[modify] https://crrev.com/b297db871b54cd58c32c96897a7a59af295ba796/ui/gfx/win/window_impl.cc
[modify] https://crrev.com/b297db871b54cd58c32c96897a7a59af295ba796/ui/views/win/hwnd_message_handler.cc
[modify] https://crrev.com/b297db871b54cd58c32c96897a7a59af295ba796/ui/views/win/hwnd_message_handler.h

Looks good in 57.0.2952.2.

The caption buttons are fixed, but the File Open dialog appears huge on the non-scaled monitor. The attached screenshot shows the problem. 

My setup:
  * High-DPI laptop display (3840x2160); 250% scaling
  * External monitor (1920x1080); No scaling.

Versions:
  * Windows 10 64-bit (Version 1607; Build 14393.693)
  * Chrome "57.0.2987.37 beta (64-bit)"

HTH, glad to see part of the problem fixed!

Deleted: Screenshot (3).png 287 KB

	Screenshot (3).png 287 KB View Download

I've been poking into this, and there's no really good solution to per-monitor dpi scaling until Creators Update rolls out, at which point DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 will become available. My personal recommendation would be to use system dpi awareness < Creators, and per monitor v2 >= Creators, as at least system will at least scale everything (including non-context area and controls) to the correct size.

raph: It works relatively well for me on Canary now on 14393. Are there specific problems that _V2 will address?

I think this is in reference to the File Open Dialog issue, which is well known for Chrome.

To answer the question here, the main priority has been to get sharp text rendering for the common case. We were willing to tolerate scaling issues inherent to the Windows per-monitor DPI story to get sharp text. We've been working with the Windows DPI team and will have been planning on incorporating these new APIs into Chrome.