Issue is not seen in today's build using M53: 53.0.2773.0/8517.0.0 (Official Build) dev-channel Lumpy and Daisy as well

Note: Issue is seen in M52: 52.0.2743.49/8350.38.0-Beta-channel- Alex (Content of the tabs is not loading properly on trying to switch the tabs).

Able to reproduce this on 53.0.2773.0/8517.0.0 dev channel Alex. Probably Alex specific.

ajha@ can you confirm this reproes on M53 Beta latest build?

Can you confirm that the DUT didn't have flags set to enable new material UI?

Valery, can you please take a look?

+1 to question in #3. Is this still reproducible on Alex? In particular past CL https://codereview.chromium.org/2224513002/ (commit refs/branch-heads/2785@{#512} - e7c901e).

Yes this is still reproduced in current stable and beta channels on Alex. There are additional symptoms though that point away from the overview mode changes:
- This is seen with the old overview (--ash-md=disabled - see attached).
- This is seen on current stable (52.0.2743) predating overview work.
- Maximizing and minimizing animations or any other time we do some scaling GPU work show bad tearing and clipping exposing wallpaper layer behind the partially clipped content.

Looks much more like a regression caused by some recent driver or Mesa push. Can somebody in Chrome OS graphics team bisect this? The bad behavior is now in stable.

Deleted: Screenshot 2016-08-08 at 3.44.10 PM.png 1.0 MB

	Screenshot 2016-08-08 at 3.44.10 PM.png 1.0 MB View Download

marcheu@ Will you have cycles to look into this one?

I tested back as far as R51-8163.0.0 and the window maximize was flickery.
I'm not 100% sure it is the same issue varkha@ demonstrated to me, but it certainly looks bad.

I'm having trouble finding older builds.

I narrowed down the builds:
good: R51-8036.0.0
 bad: R51-8049.0.0 (March 10, 2016)
There don't seem to be any alex builds between those two.

There was a mesa update in there (https://chromium-review.googlesource.com/331365) which took mesa from 4c0b4846 to 3dc2630e.
That's 4658 mesa commits over 6+ months.  Maybe something in there will jump out at marcheau@ ?

It's definitely the mesa update at fault.  When I try 8036 with mesa from 8049, it goes bad.
We can bisect the mesa changes, but that could be time consuming, because all the patches we add to mesa could need adjusting at each step of the bisect.  Hopefully most of the patches can just be ignored.

This doesn't look like a regression as previously suspected. making this non-RBS.

https://chromium-review.googlesource.com/#/c/396520/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/8f1068163c553150c58ea9864174584aacfa34a3

commit 8f1068163c553150c58ea9864174584aacfa34a3
Author: Stéphane Marchesin <marcheu@chromium.org>
Date: Tue Oct 11 01:31:13 2016

media-libs/mesa: i915g: Backport change to fix gl_FragCoord issues

This is causing different instances of corruption in our UI

BUG= chromium:606010 ,  chromium:624310 
TEST=run on zgb, no more corruption

Change-Id: I6949e687bf989ddc440af3bcb42cabde67bfa3cf
Reviewed-on: https://chromium-review.googlesource.com/396520
Commit-Ready: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>

[add] https://crrev.com/8f1068163c553150c58ea9864174584aacfa34a3/media-libs/mesa/files/12.1-i915g-fix-incorrect-gl_FragCoord-value.patch
[modify] https://crrev.com/8f1068163c553150c58ea9864174584aacfa34a3/media-libs/mesa/mesa-9999.ebuild
[modify] https://crrev.com/8f1068163c553150c58ea9864174584aacfa34a3/media-libs/mesa/mesa-12.1.0.ebuild
[rename] https://crrev.com/8f1068163c553150c58ea9864174584aacfa34a3/media-libs/mesa/mesa-12.1.0-r6.ebuild