Remove use of WS_EX_COMPOSITED for translucent windows.

Remove use of WS_EX_COMPOSITED for translucent windows.

This style causes windows to display transparent on Windows 10 creators
update with some Intel drivers on D3D9.

The style itself is unnecessary, becasue based on its documentation it
doesn't affect top-level window rendering, but affects only how child
unredirected windows (which aren't used in Aura) render on top of their
parents.

BUG=712196
Review-Url: https://codereview.chromium.org/2826343002
Cr-Commit-Position: refs/heads/master@{#466207}
Committed: https://chromium.googlesource.com/chromium/src/+/fec5a00d881dcf85a1a4334af1369402e183a302

[jbauman, 2017-04-19 23:45:18]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 23:46:01]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-20 00:51:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-20 00:51:10]

Dry run: This issue passed the CQ dry run.

[jbauman, 2017-04-20 00:53:49]

jbauman@chromium.org changed reviewers:
+ sky@chromium.org

[sky, 2017-04-20 17:26:28]

https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h
File ui/gfx/win/constants.h (right):

https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h#newc...
ui/gfx/win/constants.h:13: const wchar_t kChromeWindowTranslucent[] =
L"Chrome.WindowTranslucent";
We also have ui/base/win/internal_constants.h. Can this move there? If it can't
for some reason, can you move the other one here? Also, should this be extern?

https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
File ui/views/widget/widget_hwnd_utils.cc (right):

https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
ui/views/widget/widget_hwnd_utils.cc:158: (ui::win::IsAeroGlassEnabled() ||
params.force_software_compositing));
What happens if IsAeroGlassEnabled() changes during the lifetime of the window?
For example, remove desktop is used or something?

https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
File ui/views/win/hwnd_message_handler.h (right):

https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
ui/views/win/hwnd_message_handler.h:714: bool translucent_ = false;
Please rename this is_translucent_ and the setter/getter to match.

[jbauman, 2017-04-20 21:31:38]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-20 21:33:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jbauman, 2017-04-20 21:56:31]

PTAL.

On 2017/04/20 17:26:28, sky wrote:
> https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h
> File ui/gfx/win/constants.h (right):
> 
>
https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h#newc...
> ui/gfx/win/constants.h:13: const wchar_t kChromeWindowTranslucent[] =
> L"Chrome.WindowTranslucent";
> We also have ui/base/win/internal_constants.h. Can this move there? If it
can't
> for some reason, can you move the other one here? Also, should this be extern?
> 
Done.

>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> File ui/views/widget/widget_hwnd_utils.cc (right):
> 
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> ui/views/widget/widget_hwnd_utils.cc:158: (ui::win::IsAeroGlassEnabled() ||
> params.force_software_compositing));
> What happens if IsAeroGlassEnabled() changes during the lifetime of the
window?
> For example, remove desktop is used or something?
> 
The same as now, I think. If we change away from aero then if the window's drawn
with D3D then the part of the window inside the window region will look
essentially like it's blended with black, so translucent windows can have an
ugly black border.
If we change to aero then the window won't be able to be drawn as translucent,
but it shouldn't try to because of how it was created.

To fix that, one option would be to tell all the widgets that they need to
change their frames to not be translucent or to draw into their parent window
instead.
Or we'd need to do a readback from the D3D swapchain and upload that to a
layered window.

Windows 7 is the last version where aero could be disabled, so this problem
should eventually go away.

>
https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
> File ui/views/win/hwnd_message_handler.h (right):
> 
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
> ui/views/win/hwnd_message_handler.h:714: bool translucent_ = false;
> Please rename this is_translucent_ and the setter/getter to match.

Done.

[sky, 2017-04-20 22:05:40]

On 2017/04/20 21:56:31, jbauman wrote:
> PTAL.
> 
> On 2017/04/20 17:26:28, sky wrote:
> > https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h
> > File ui/gfx/win/constants.h (right):
> > 
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h#newc...
> > ui/gfx/win/constants.h:13: const wchar_t kChromeWindowTranslucent[] =
> > L"Chrome.WindowTranslucent";
> > We also have ui/base/win/internal_constants.h. Can this move there? If it
> can't
> > for some reason, can you move the other one here? Also, should this be
extern?
> > 
> Done.
> 
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> > File ui/views/widget/widget_hwnd_utils.cc (right):
> > 
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> > ui/views/widget/widget_hwnd_utils.cc:158: (ui::win::IsAeroGlassEnabled() ||
> > params.force_software_compositing));
> > What happens if IsAeroGlassEnabled() changes during the lifetime of the
> window?
> > For example, remove desktop is used or something?
> > 
> The same as now, I think. If we change away from aero then if the window's
drawn
> with D3D then the part of the window inside the window region will look
> essentially like it's blended with black, so translucent windows can have an
> ugly black border.
> If we change to aero then the window won't be able to be drawn as translucent,
> but it shouldn't try to because of how it was created.
> 
> To fix that, one option would be to tell all the widgets that they need to
> change their frames to not be translucent or to draw into their parent window
> instead.
> Or we'd need to do a readback from the D3D swapchain and upload that to a
> layered window.

We potentially change how we draw the frame, but I'm wondering if the
is_translucent part should be updated? Is there a reason not to recalculate it?

> 
> Windows 7 is the last version where aero could be disabled, so this problem
> should eventually go away.
> 
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
> > File ui/views/win/hwnd_message_handler.h (right):
> > 
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/win/hwnd_message_h...
> > ui/views/win/hwnd_message_handler.h:714: bool translucent_ = false;
> > Please rename this is_translucent_ and the setter/getter to match.
> 
> Done.

[jbauman, 2017-04-20 22:15:38]

On 2017/04/20 22:05:40, sky wrote:
> On 2017/04/20 21:56:31, jbauman wrote:
> > PTAL.
> > 
> > On 2017/04/20 17:26:28, sky wrote:
> > > https://codereview.chromium.org/2826343002/diff/1/ui/gfx/win/constants.h
> > > File ui/gfx/win/constants.h (right):
> > 
> > >
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> > > File ui/views/widget/widget_hwnd_utils.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2826343002/diff/1/ui/views/widget/widget_hwnd...
> > > ui/views/widget/widget_hwnd_utils.cc:158: (ui::win::IsAeroGlassEnabled()
||
> > > params.force_software_compositing));
> > > What happens if IsAeroGlassEnabled() changes during the lifetime of the
> > window?
> > > For example, remove desktop is used or something?
> > > 
> > The same as now, I think. If we change away from aero then if the window's
> drawn
> > with D3D then the part of the window inside the window region will look
> > essentially like it's blended with black, so translucent windows can have an
> > ugly black border.
> > If we change to aero then the window won't be able to be drawn as
translucent,
> > but it shouldn't try to because of how it was created.
> > 
> > To fix that, one option would be to tell all the widgets that they need to
> > change their frames to not be translucent or to draw into their parent
window
> > instead.
> > Or we'd need to do a readback from the D3D swapchain and upload that to a
> > layered window.
> 
> We potentially change how we draw the frame, but I'm wondering if the
> is_translucent part should be updated? Is there a reason not to recalculate
it?
> 
I think with the WS_EX_COMPOSITED removed we could probably remove the check for
IsAeroGlassEnabled here. But that seems a bit riskier to me and we're hitting
bug 712196 in stable, so I'd want to avoid doing that in this patch so it's a
bit safer to merge back.

[sky, 2017-04-20 22:26:29]

Ok, LGTM

[commit-bot: I haz the power, 2017-04-20 22:37:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-20 22:37:46]

Dry run: This issue passed the CQ dry run.

[jbauman, 2017-04-21 01:06:32]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2017-04-21 01:06:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-21 01:10:52]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1492736792398790,
"parent_rev": "e0800c0393765b299e3fcd81f2d97b8bbe997a2f", "commit_rev":
"fec5a00d881dcf85a1a4334af1369402e183a302"}

[commit-bot: I haz the power, 2017-04-21 01:11:02]

Description was changed from

==========
Remove use of WS_EX_COMPOSITED for translucent windows.

This style causes windows to display transparent on Windows 10 creators
update with some Intel drivers on D3D9.

The style itself is unnecessary, becasue based on its documentation it
doesn't affect top-level window rendering, but affects only how child
unredirected windows (which aren't used in Aura) render on top of their
parents.

BUG=712196
==========

to

==========
Remove use of WS_EX_COMPOSITED for translucent windows.

This style causes windows to display transparent on Windows 10 creators
update with some Intel drivers on D3D9.

The style itself is unnecessary, becasue based on its documentation it
doesn't affect top-level window rendering, but affects only how child
unredirected windows (which aren't used in Aura) render on top of their
parents.

BUG=712196

Review-Url: https://codereview.chromium.org/2826343002
Cr-Commit-Position: refs/heads/master@{#466207}
Committed:
https://chromium.googlesource.com/chromium/src/+/fec5a00d881dcf85a1a4334af136...
==========

[commit-bot: I haz the power, 2017-04-21 01:11:03]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/fec5a00d881dcf85a1a4334af136...