Since custom title-bars were enabled on Windows, Chrome uses an opaque surface since it draws the title-bar by itself and doesn't need to blend with OS drawn title-bar.

Direct composition was recently disabled when hardware overlays are unavailable, and that caused a power regression on some hardware that doesn't support overlays.

With direct composition, Chrome managed the swap chain, and set the proper alpha flag based on the has_alpha flag in display compositor's ResizeCHROMIUM call, but without direct composition i.e. GLSurfaceEGL, we ignore the has_alpha flag.  I strongly suspect that this change in behavior caused the power regression.

ANGLE uses alpha size from EGLConfig to determine whether to use DXGI_ALPHA_MODE_IGNORE or DXGI_ALPHA_MODE_PREMULTIPLIED for a swap chain.

https://cs.chromium.org/chromium/src/third_party/angle/src/libANGLE/renderer/d3d/d3d11/Renderer11.cpp?rcl=2197dc5290522549f5c9421b48d4eb547f4068e2&l=1259

I tried a fix by overriding alpha size to 0 for choosing an EGLConfig when has_alpha is false, but piman@ suspects there's a risk that MakeCurrent might fail when switching between surfaces with different EGLConfigs.  This may not be true for ANGLE, but it seems like a very roundabout way of achieving the end result.

I propose that we add a new window attribute EGL_IGNORE_ALPHA_ANGLE (default EGL_FALSE), that's used to set the swap chain alpha flag in conjunction with alpha size check i.e. DXGI_ALPHA_MODE_PREMULTIPLIED flag if alpha_size > 0 && EGL_IGNORE_ALPHA_ANGLE == EGL_FALSE, otherwise set DXGI_ALPHA_MODE_IGNORE.  Seems simple enough to implement quickly.