Windows: Remove CefEnableHighDPISupport function which is no longer needed

[magreenblatt]

Original report by Henrik Andersson (Bitbucket: Henrik Andersson).

---

It seems that CEF 108+ sets the DPI awareness of the current process to “Per monitor DPI aware” if no value has been previously set. This is mainly a problem for applications which did not set this value explicitly to “DPI unaware” or “System DPI aware”, either via API or in their manifest.

I noticed this when running a Windows Forms application with a CEF control created using Cefglue. I have not attempted to reproduce with the sample applications. Settings the process (and subprocess) DPI awareness via SetProcessDpiAwareness to “DPI unaware” before loading the CEF seems to resolve the issue.

Reporting this as an issue in case this is unexpected behavior.

Guessing this may be related to the fix for #3359

[magreenblatt]

Looks like the behavior changed in this Chromium commit

Additionally, as a refactor to move responsibility out of the embedder
this change moves the existing EnableHighDPISupport calls in
chrome_exe_main_win.cc into the respective GpuMain &
BrowserMainRunnerImpl for the GPU & Browser processes.

What is the use case for running with “DPI unaware”?

[magreenblatt]

Note that leaving this new Chromium behavior unchanged would allow us to remove the CefEnableHighDPISupport function.

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

I’m also did not understand issue. I guess, what there is nothing with CEF, nor CefGlue.

Any application should declare own DPI awareness, which is by default controlled by app.manifest. Surely you can use API calls to do such things, but still, there is no any sense to even touch this calls, because your application must specify correct app.manifest anyway.

Note, what CEF/Chromium anyway also requires to include correct windows common controls 6.0.0 into manifest.

Also, chromium is DPI aware by default, and trying to working in other modes, might cause unexpected behaviors. So, actually, there is no choice.

‌

What is the use case for running with “DPI unaware”?

Unaware means what no awareness is specified in manifest and automatic scaling will be applied to windows. Which is literally always bad choice for any application (assuming past ~10 years).

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

Sorry, bad tradition - i'm hasty on words and completely unclear.

I meant what any app which integrates CEF 108+ is can't be considered legacy, and app owner should setup desired dpi awareness anyway.

I'm not sure why cef have special api to enable hidpi (does it touches some hidden statics?). If it nothing than platform call alias then it never was needed in first place. (Still all relevant processes should be configured properly, and this is hidden knowledge.)

From my personal point of view - new behavior is acceptable. It was never specified before and nor defined right now. If someone really care about default windows semantics, then thin shim can mitigate this, by setting current effective awareness explicitly. But this from my personal point again is not a realistic case.

‌

[magreenblatt]

From the CEF documentation:

Call during process startup to enable High-DPI support on Windows 7 or newer.

Older versions of Windows should be left DPI-unaware because they do not support DirectWrite and GDI fonts are kerned very badly.

So it sounds like there were historical reasons to not call it with older (now unsupported) Windows versions, and we can probably remove this function today. Also, comments on the Chromium commit suggest that DirectWrite will misbehave with incorrect HighDPI settings.

‌

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

And for completion: Win7 is no more supported (i guess it currently just work but without guarantee), but W10 offer 2 multi-monitor awareness modes (2 versions), and Chrome compliant with them. E.g. just summary:

1. Apps must declare manifest
2. All modes are available, compatible
3. All modes configurable ny client by OS calls

So, really, seems like there is no need any add action from CEF side.

‌

[magreenblatt]

• changed title from "CEF sets Windows process DPI awareness if unset" to "Windows: Remove CefEnableHighDPISupport function which is no longer needed"

[magreenblatt]

Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).

---

Marshall, DirectWrite did not counts: it already misbehave even on W10 because there is two API versions of DW inside W10 timeline (RS1 vs later). It works only because of them directly supported in code and emulating missing functionality on Win7. Yup.

‌

And I'm did not accept CEF docs as argue (of what?). No matter.

‌

I just vote for common sense: every app must have manifest. And there is place where app chooses dpi awareness, together with other required stuff.

[magreenblatt]

win: Remove CefEnableHighDPISupport function (fixes issue #3452)

High-DPI support is now enabled by default in Chromium.

→ <<cset f3b570cf8e3a (bb)>>

[magreenblatt]

• changed state from "new" to "resolved"