Interesting! Does this repro if you turn off draw-occlusion (feature name is 'DrawOcclusion' [1])?

[1] https://cs.chromium.org/chromium/src/components/viz/common/features.cc?l=15

Still repros with --disable-features=DrawOcclusion

I'll also mention I can't repro this on the desktop (over chrome remote desktop). I'll try forcing 2x and see if that makes a difference.

And I cannot repro on desktop even without chrome remote desktop. I didn't try other scale factors, though.

I couldn't repro on the desktop with --force-device-scale-factor=2.

James, is this a clean profile, or might you have other things running (say the tap-visualizer)? 

I don't think I had anything else running.

This was with a test consumer gmail account (jamescooktest2@gmail.com). I can give you the credentials if you need it. It was a pretty unremarkable account, just a couple chrome apps installed.

I don't think ARC was running, either.

Sadrul theorized maybe this has something to do with gpu memory. I tried this on a pixel1 and couldn't repro. I did run a trace though, and the gpu memory used by shortcut_viewer_app was pretty low, around 2mb.

I tried on link and eve with 69.0.3451.0 and haven't been able to repro.

In case it helps, the chrome os version I was using is R69-10758.0.0

While working on another bug, I might have found something similar with consistent repro:
1) Apply empty_window.patch (or empty_modal_window.patch)
2) Run chrome --keyboard-shortcut-viewer-app (doesn't repro without the switch)
3) Press Ctrl-Alt-/ to show the keyboard shortcut viewer and test empty window.
4) Drag the test empty window around over the KSV and browser windows.
Expected: The underlying KSV and browser windows look the same when hovered.
Actual: The underlying windows have graphical errors (see screenshots)

The nature of the graphical errors seem related to this issue.
(I've seen black/white rects, undimmed rects, similar glitches)
I'm not sure if we care to support empty windows, but this might expose a defect.

Using --disable-features=DrawOcclusion doesn't affect the outcome.

Deleted: empty_window.patch 781 bytes

empty_window.patch 781 bytes Download

Deleted: empty_window.png 13.3 KB

	empty_window.png 13.3 KB View Download

Deleted: empty_modal_window.patch 12.6 KB

empty_modal_window.patch 12.6 KB Download

Deleted: empty_modal_window.png 16.3 KB

	empty_modal_window.png 16.3 KB View Download

ksv is now enabled via a feature, so have to use  --enable-features=KeyboardShortcutViewer.

Actually, it's --enable-features=KeyboardShortcutViewerApp .

I got a repro based on msw@'s patch:

We need --enable-features=KeyboardShortcutViewerApp now.

I think what's going on here is the SurfaceLayer is labeled as opaque but it has no surface. We drop layers beneath and that's what's going on.

For the case above, I think maybe we're not filling in the whole background and it's marked as opaque so we'll occasionally drop quads beneath. A simple solution in both cases is to mark the SurfaceLayer as not opaque. That might affect performance but it'll mitigate the issue for the time being until performance becomes an issue.

Are you referring to the SurfaceLayer created in the client for the window?

Now that I look into it more, maybe it's not the surface layer. It might be another layer in the app that's marked as opaque when it shouldn't be.

I see the bug.

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

commit f049f6e101cada7bdb598e510a1aa1a41f9c5c68
Author: Scott Violet <sky@chromium.org>
Date: Mon Jun 18 20:44:52 2018

chromeos: fix opacity in ash

The client was not always passing in the right translucent value, leading
to the window being marked opaque on the server when it isn't.

BUG= 849380 
TEST=none

Change-Id: I39f73a9ede381f0310a8532bc76ce700007f1352
Reviewed-on: https://chromium-review.googlesource.com/1103701
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568149}
[modify] https://crrev.com/f049f6e101cada7bdb598e510a1aa1a41f9c5c68/ui/views/mus/desktop_window_tree_host_mus.cc
[modify] https://crrev.com/f049f6e101cada7bdb598e510a1aa1a41f9c5c68/ui/views/mus/mus_client.cc
[modify] https://crrev.com/f049f6e101cada7bdb598e510a1aa1a41f9c5c68/ui/views/mus/mus_client.h