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

commit 458e50ea1e561feeb779ff7a26310e59b43fc0d6
Author: sadrul <sadrul@chromium.org>
Date: Wed Mar 15 17:44:31 2017

compositor: Change how attributes are set during ui::Layer::Clone().

A solid-color layer with SK_ColorTRANSPARENT color can be marked as
opaque, as is done in ash-mus to reduce overdraw (crrev.com/456910). When
Clone()ing the Layer, the opaque-ness of the layer is cloned first, and
then the color is set. However, ui::Layer can turn off the opaque-ness
when setting the color, if color is transparent. So, set up color etc.
of a ui::Layer first when cloning, before setting remaining properties.

Without this fix, anytime a window is maximized/restored (which uses
cloned layers), ash loses the overdraw optimization.

BUG= 701653 

Review-Url: https://codereview.chromium.org/2749993002
Cr-Commit-Position: refs/heads/master@{#457126}

[modify] https://crrev.com/458e50ea1e561feeb779ff7a26310e59b43fc0d6/ui/compositor/layer.cc
[modify] https://crrev.com/458e50ea1e561feeb779ff7a26310e59b43fc0d6/ui/compositor/layer_unittest.cc

AFAIK: not required for mushrome so reducing priority

I think the UI in general can be a little bit smarter to help with overdraw. But I am not actively working on this at the moment.

Migrating from Proj-Mustash-Aura to components Internals>Aura

I'm assuming we'll need to investigate this for single-process mash. There is a general umbrella bug for performance as well: 

Sadrul, are there specific things that need to be done here for single-process-mash? If so, could you point me in the right direction?

Here's a description of overdraw: https://www.chromium.org/developers/how-tos/gpu-overdraw-debugging-tool . AFAICT overdraw between mash and classic is the same. I'm closing this out.

I've attached some permutations that Sadrul asked for. They were created using the command line tool 'screenshot' which results in some tearing.