Make MF Utility Process DPI Aware

This change makes the MF Utility Process DPI Aware by calling
EnableHighDPISupport in UtilityMain.

This is needed to allow the Media Foundation Media Engine to correctly
identify the monitor where the Direct Composition surface for the
content will be presented. In the case of SW DRM this is required to
set OPM properties on the monitor. For HW DRM this is required to allow
proper querying of HW properties of the target monitor. Failures here
could result in no video output.

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.

A sample setup where the MF Utility Process may be required to be DPI
aware (SW DRM) would be a 4K monitor @ 150% DPI scaling & another 1080P
monitor @ 150% positioned below that monitor. Without DPI awareness if
the DComp surface being presented to is on the secondary monitor the
Media Engine would calculate the primary monitor's virtual coordinates
as 3840 x 2160 at 0,0 and the secondary monitor as 1920 x 1080 at 0,
2160. In reality the virtual coordinates of the primary monitor would
be 2560 x 1440 at 0,0 so we'd expect the secondary monitor at 1280 x
720 at 0, 1440. When the engine is given the target DComp surface at
1280 x 720 at 0, 1440 it will end up identifying this as within the
primary monitor's region (since it calculates that region as 3840 x
2160 which will completely enclose 0, 1440, 1280, 2160). As a result
the primary monitor will be marked with any properties required for the
DRM engine's presentation.

A couple of blink web tests (virtual/scalefactor*/fast/hidpi) ended up
needing re-baselining. This appears to be a result of moving the
EnableHighDPISupport for Browser out of wWinMain in chrome_exe_main_win
and into BrowserMainRunnerImpl::Initialize. When content shell is
running BrowserMainRunnerImpl::Initialize will be called (in turn
enabling High DPI Support) however the previous wWinMain code was not
called with an empty process Id, thus it was not calling
EnableHighDPISupport. As a result in this change in calling
EnableHighDPISupport there were some minor discrepancies in OS UX, like
scroll bars, for some of the expected images.

Bug: 1369598
Change-Id: Ia64173cea960da9bdf23aad878cb199f44a4363a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3898640
Auto-Submit: William Carr <wicarr@microsoft.com>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/main@{#1057058}

chrome/app/chrome_exe_main_win.cc

@@ -380,10 +380,6 @@ int main() {
   // The exit manager is in charge of calling the dtors of singletons.
   base::AtExitManager exit_manager;
 
-  // Only enable High DPI support for browser and GPU process.
-  if (process_type.empty() || process_type == switches::kGpuProcess)
-    base::win::EnableHighDPISupport();
-
   if (AttemptFastNotify(*command_line))
     return 0;
 

content/browser/browser_main_runner_impl.cc

@@ -36,6 +36,7 @@
 #endif
 
 #if BUILDFLAG(IS_WIN)
+#include "base/win/win_util.h"
 #include "base/win/windows_version.h"
 #include "ui/base/win/scoped_ole_initializer.h"
 #endif
@@ -91,6 +92,7 @@ int BrowserMainRunnerImpl::Initialize(MainFunctionParams parameters) {
     notification_service_ = std::make_unique<NotificationServiceImpl>();
 
 #if BUILDFLAG(IS_WIN)
+    base::win::EnableHighDPISupport();
     // Ole must be initialized before starting message pump, so that TSF
     // (Text Services Framework) module can interact with the message pump
     // on Windows 8 Metro mode.

content/gpu/gpu_main.cc

@@ -80,6 +80,7 @@
 #if BUILDFLAG(IS_WIN)
 #include "base/trace_event/trace_event_etw_export_win.h"
 #include "base/win/scoped_com_initializer.h"
+#include "base/win/win_util.h"
 #include "base/win/windows_version.h"
 #include "media/gpu/windows/dxva_video_decode_accelerator_win.h"
 #include "media/gpu/windows/media_foundation_video_encode_accelerator_win.h"
@@ -218,6 +219,7 @@ int GpuMain(MainFunctionParams parameters) {
   base::TimeTicks start_time = base::TimeTicks::Now();
 
 #if BUILDFLAG(IS_WIN)
+  base::win::EnableHighDPISupport();
   base::trace_event::TraceEventETWExport::EnableETWExport();
 
   // Prevent Windows from displaying a modal dialog on failures like not being

content/utility/utility_main.cc

@@ -70,6 +70,7 @@
 
 #if BUILDFLAG(IS_WIN)
 #include "base/rand_util.h"
+#include "base/win/win_util.h"
 #include "base/win/windows_version.h"
 #include "sandbox/win/src/sandbox.h"
 
@@ -246,6 +247,21 @@ int UtilityMain(MainFunctionParams parameters) {
     UNREFERENCED_PARAMETER(shell32_pin);
   }
 
+  // Not all utility processes require DPI awareness as this context only
+  // pertains to certain workloads & impacted system API calls (e.g. UX
+  // scaling or per-monitor windowing). We do not blanket apply DPI awareness
+  // as utility processes running within a kService sandbox with the Win32K
+  // Lockdown policy applied may crash when calling EnableHighDPISupport. See
+  // crbug.com/978133.
+  if (sandbox_type == sandbox::mojom::Sandbox::kMediaFoundationCdm) {
+    // The Media Foundation Utility Process needs to be marked as DPI aware so
+    // the Media Engine & CDM can correctly identify the target monitor for
+    // video output. This is required to ensure that the proper monitor is
+    // queried for hardware capabilities & any settings are applied to the
+    // correct monitor.
+    base::win::EnableHighDPISupport();
+  }
+
   if (!sandbox::policy::IsUnsandboxedSandboxType(sandbox_type) &&
       sandbox_type != sandbox::mojom::Sandbox::kCdm &&
       sandbox_type != sandbox::mojom::Sandbox::kMediaFoundationCdm &&