Is there any way to test this without a touch screen?

With respect to comment #1,

@kylechar: This issue is tested on Windows 10 (Touch device) and found that issue is touch specific and cannot be reproduced using other non-touch devices or click events. Hence, there is no other way to test without a touch screen.

I've reproduced the issue. The blue touch dot is drawn by Windows. I guess it's drawn with transparency over top of the omnibox popup HWND. It looks like Windows is blending with old HWND content when not using a layered window.

FYI the same effect can be reproduced without a touch display if you turn on the pointer trails.

I'm not really sure why this is broken exactly. I'm investigating now, but worst case if I can't get something working quickly I can change M68 back to using layered windows for HWNDs with transparency.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/57631e9ebf5bff0179e710a7f949d8e1fe72676d

commit 57631e9ebf5bff0179e710a7f949d8e1fe72676d
Author: kylechar <kylechar@chromium.org>
Date: Fri Jun 01 20:51:14 2018

Use layered windows for Win8+ again.

Start using layered windows for HWNDs that need to support transparency
on Windows 8 and higher again. DWM supports alpha channels for HWNDs
natively. This seemed to work well, however there is a problem with
touch highlight and pointer trail features. Windows blends the area near
the cursor with HWND content below it. When not using layered windows
there is a bug where the area that is redrawn for highlight/trail is
older content than the rest of the HWND. This is a return to the
behaviour found in M67.

Bug:  843974 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I1e6dc7e774c5f70653352006f4f548a15862594e
Reviewed-on: https://chromium-review.googlesource.com/1082793
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563785}
[modify] https://crrev.com/57631e9ebf5bff0179e710a7f949d8e1fe72676d/components/viz/common/display/use_layered_window.cc
[modify] https://crrev.com/57631e9ebf5bff0179e710a7f949d8e1fe72676d/components/viz/common/display/use_layered_window.h
[modify] https://crrev.com/57631e9ebf5bff0179e710a7f949d8e1fe72676d/components/viz/service/display_embedder/software_output_device_win.cc

I spent a while looking into this and I wasn't figure out exactly what's happening. For both HWNDs that were completely opaque and HWNDs that had transparent regions we were using the same code. SoftwareOutputDeviceWinDirect would call skia::CopyHDC() to copy pixels from the SkCanvas DC to the HWND DC. Internally skia::CopyHDC() was calling BitBlt() to copy pixels. BitBlt() isn't really alpha channel aware but it copies the alpha channel which works.

For some reason, if the the HWND had any pixels with an alpha channel value that wasn't 255 something different happened. I guess this makes sense, as DWM needs to alpha blend that HWND contents with anything below it, but it had the side effect that pointer trails/tough highlight would blend with old HWND content. When the region the pointer trail was redrawing, which had old HWND content, was placed on top of the new HWND content it didn't look right.

Switching back to using layered windows for Windows 8/10 is a return to existing behaviour used up to M67 so it shouldn't be an issue for non OOP-D. The reason for the change is that with OOP-D we couldn't draw to a browser process layered window for the GPU process. On Windows 7 we also can't make a layered window that is child window. I added SoftwareOutputDeviceWinProxy  to paint to a backing buffer in the GPU process and draw to it in the browser process but that adds IPC overhead. This implementation is only used with OOP-D.

To avoid the IPC overhead with Windows 8/10 and OOP-D an implementation that uses a child layered window in the GPU process is possible.

Requesting merge of #5 to M68. This fixes a pretty glaring graphics glitch and it's very low risk as it's just a return to the behaviour we had in M67.

Approved for 68: branch:3440

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/37ec295736aad2f216bbadc7432471a6b811c781

commit 37ec295736aad2f216bbadc7432471a6b811c781
Author: kylechar <kylechar@chromium.org>
Date: Mon Jun 04 18:09:30 2018

Use layered windows for Win8+ again.

Start using layered windows for HWNDs that need to support transparency
on Windows 8 and higher again. DWM supports alpha channels for HWNDs
natively. This seemed to work well, however there is a problem with
touch highlight and pointer trail features. Windows blends the area near
the cursor with HWND content below it. When not using layered windows
there is a bug where the area that is redrawn for highlight/trail is
older content than the rest of the HWND. This is a return to the
behaviour found in M67.

Bug:  843974 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I1e6dc7e774c5f70653352006f4f548a15862594e
Reviewed-on: https://chromium-review.googlesource.com/1082793
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#563785}(cherry picked from commit 57631e9ebf5bff0179e710a7f949d8e1fe72676d)
Reviewed-on: https://chromium-review.googlesource.com/1085528
Reviewed-by: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#142}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/37ec295736aad2f216bbadc7432471a6b811c781/components/viz/common/display/use_layered_window.cc
[modify] https://crrev.com/37ec295736aad2f216bbadc7432471a6b811c781/components/viz/common/display/use_layered_window.h
[modify] https://crrev.com/37ec295736aad2f216bbadc7432471a6b811c781/components/viz/service/display_embedder/software_output_device_win.cc

Update: 

Retested the above issue on latest Dev build #68.0.3440.15 for Windows 10 (Touch device) and the issue is fixed.

Kindly refer the attached screen-cast for reference.

Thank you..!!

Deleted: Fixed Video.mp4 632 KB

	Fixed Video.mp4 632 KB View Download