Have Chrome draw top window border when using custom titlebar.

chrome/browser/themes/theme_service_win.cc

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/themes/theme_service_win.h"
 
+#include <algorithm>
+
 #include "base/bind.h"
+#include "base/numerics/safe_conversions.h"
 #include "base/win/windows_version.h"
 #include "chrome/browser/themes/theme_properties.h"
 #include "chrome/grit/theme_resources.h"
 #include "skia/ext/skia_utils_win.h"
 #include "ui/base/win/shell.h"
 
 ThemeServiceWin::ThemeServiceWin() {
   // This just checks for Windows 10 instead of calling ShouldUseDwmFrameColor()
   // because we want to monitor the frame color even when a custom frame is in
   // use, so that it will be correct if at any time the user switches to the
@@ skipping 14 matching lines @@
 bool ThemeServiceWin::ShouldUseNativeFrame() const {
   return !HasCustomImage(IDR_THEME_FRAME) && ui::win::IsAeroGlassEnabled();
 }
 
 SkColor ThemeServiceWin::GetDefaultColor(int id, bool incognito) const {
   if (ShouldUseDwmFrameColor()) {
     // Active native windows on Windows 10 may have a custom frame color.
     if (id == ThemeProperties::COLOR_FRAME)
       return dwm_frame_color_;
 
+    if (id == ThemeProperties::COLOR_ACCENT_BORDER)
+      return dwm_accent_color_;
+
     // Inactive native windows on Windows 10 always have a white frame.
     if (id == ThemeProperties::COLOR_FRAME_INACTIVE)
         return SK_ColorWHITE;
   }
 
   return ThemeService::GetDefaultColor(id, incognito);
 }
 
 bool ThemeServiceWin::ShouldUseDwmFrameColor() const {
   return ShouldUseNativeFrame() &&
          (base::win::GetVersion() >= base::win::VERSION_WIN10);
 }
 
+// This can accept alpha < 0 or > 1.

[Peter Kasting, 2016/10/06 08:02:46]

...But we never call it with < 0, right?

Graphically, I don't really understand what the equation below does when we call
with alpha > 1.  Sure, the math can work out, but what does it _mean_?

[Bret, 2016/10/06 20:48:09]

Yeah don't mention it's allowed to be "out of bounds" if that's not useful in
practice. I would call it "color_balance" maybe? I was calling it "alpha" only
because this is the alpha blending formula. On the other hand if we end up doing
something different below we can go back to using utility functions (which would
be nice).

+static uint8_t alpha_blend_component(uint8_t a, uint8_t b, float alpha) {
+  return base::saturated_cast<uint8_t>(std::round(a * alpha + b * (1 - alpha)));
+}
+
 void ThemeServiceWin::OnDwmKeyUpdated() {
   // Attempt to read the accent color.
   DWORD accent_color, color_prevalence;
   dwm_frame_color_ =
       ((dwm_key_->ReadValueDW(L"ColorPrevalence", &color_prevalence) ==
         ERROR_SUCCESS) &&
        (color_prevalence == 1) &&
        (dwm_key_->ReadValueDW(L"AccentColor", &accent_color) == ERROR_SUCCESS))
           ? skia::COLORREFToSkColor(accent_color)
           : SK_ColorWHITE;
 
+  dwm_accent_color_ = SK_ColorWHITE;

[Peter Kasting, 2016/10/06 08:02:46]

I didn't check: for native drawing, does the ColorPrevalence value above affect
whether the colorization color value is ignored?

[Bret, 2016/10/06 20:48:09]

No, the border is always colored the same way even if ColorPrevalence is 0.

+  DWORD colorization_color, colorization_color_balance;
+  if ((dwm_key_->ReadValueDW(L"ColorizationColor", &colorization_color) ==
+       ERROR_SUCCESS) &&
+      (dwm_key_->ReadValueDW(L"ColorizationColorBalance",
+                             &colorization_color_balance) == ERROR_SUCCESS)) {
+    constexpr DWORD max_colorization_balance = 120u;
+    // Alpha can be > 1.0 if the accent color is taken from the background and
+    // either the background is a solid color or was just changed to a
+    // slideshow.

[Peter Kasting, 2016/10/06 08:02:46]

Is it true that the colorization color balance is always 100 or less, or else
120?  Or does it take on values in the range between 100 and 120?

This gets back to my question above; I don't really understand what these values
mean conceptually.

Underneath this question, I'm also asking if Windows' Anniversary Update
behavior is really something that makes any sense, that we should imitate
slavishly, or if it's just a bug, that produces weirder behavior in edge cases
than the pre-Anniversary algorithm and does nothing else better.  If there's a
conceptual way to define what's going on here so it has some plausible reason
for existence, even if it's an unusual one, then OK, but if this is just totally
broken in Windows natively, then I don't know whether I want to reproduce logic
that makes no sense, especially if they go and fix it in the next update.

[Bret, 2016/10/06 20:48:09]

I just tried thrashing my own registry values on 1511 and it's using
ColorizationColorBalance=27(???) when it's out of bounds (with
ColorizationColor=#FF00FF it gives me a border color of #E39EE3). Cf Edge's top
border, which seems to always be using ColorizationColorBalance=80, though that
means it never matches Windows. This seems to match anniversary's "restart dwm
but not explorer" case.

It also seems like 100 is the actual max. Past that point Edge and Windows start
doing different things (even below 120). Unless that too is different on
anniversary edition I'm tempted to just match what Edge does and not worry about
it too much, since ColorizationColorBalance getting set to such a flagrantly
out-of-bounds value does seem like a bug.

+    float alpha =
+        std::min(colorization_color_balance, max_colorization_balance) / 100.f;
+    const uint8_t gray_level = 0xd9;

[Peter Kasting, 2016/10/06 08:02:47]

Nit: Comment where this comes from.  More accurately, comment above what all
these concepts mean, by describing roughly what the colorization color and color
balance mean.  Somewhere in such an explanation, a phrase like "the color
balance controls the blend between the colorization color and a neutral #D9D9D9"
would explain why this number is down here.

+
+    // colorization_color's alpha can be 0xc4 or 0.

[Peter Kasting, 2016/10/06 08:02:47]

Nit: As Bret noted, this isn't really an alpha value.  Explain that it's not an
alpha value, noting what these main, as a means to explaining why it's both safe
and necessary to overwrite this.

+    SkColor input_color = SkColorSetA(colorization_color, 0xff);
+
+    dwm_accent_color_ = SkColorSetRGB(
+        alpha_blend_component(SkColorGetR(input_color), gray_level, alpha),
+        alpha_blend_component(SkColorGetG(input_color), gray_level, alpha),
+        alpha_blend_component(SkColorGetB(input_color), gray_level, alpha));
+  }
+
   // Watch for future changes.
   if (!dwm_key_->StartWatching(base::Bind(
           &ThemeServiceWin::OnDwmKeyUpdated, base::Unretained(this))))
     dwm_key_.reset();
 }