Fix three causes of blank thumbnails [2nd land]

Fix three causes of blank thumbnails [2nd land]

All three of these fixes are required to address the devil case
http://crbug.com/659459, and some of them also help with some of the
other flickers.

1. In onPageLoadStarted, the URL can be the same as before, in
particular because history-item scroll offset restores count as load
starts.  These history restores often fire late in page load, *after*
the thumbnail was taken, leading to immediately throwing out the
thumbnail we just took earlier in page load.  Switch to the "invalidate"
path which only ejects the thumbnail if the URL changed.

2. In CacheTab, which is often called just to refresh the thumbnail with
the latest state, if readback is currently impossible, we used to remove
the old thumbnail.  Keep it instead.

3. Switch to the more reliable Surfaces-based mechanism for readback.
The layer-based mechanism often outputs black screenshots in difficult
racy cases like onStop readbacks.  The Surface-based mechanism had been
reverted because it tickles a driver bug on Nexus 7 2013 that itself causes
some flickers, but I verified that the repro scenario for that is quite
niche, and even on Nexus 7 it's probably less severe than the black
screenshot problem this fixes.

TBR=tedchoc@chromium.org
BUG=636630, 640561, 659459, 646336
Committed: https://crrev.com/d9c930e47745312f5cc8a5b9d4e6802c18f8b5de
Cr-Commit-Position: refs/heads/master@{#432411}

[aelias_OOO_until_Jul13, 2016-11-16 02:28:15]

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

[commit-bot: I haz the power, 2016-11-16 02:28:42]

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

[aelias_OOO_until_Jul13, 2016-11-16 03:03:48]

The previous version of this http://crrev.com/432322 collided with indirectly
conflicting patch http://crrev.com/432312 and was reverted.  Relanding this with
TBR to reuse lgt'm.

[aelias_OOO_until_Jul13, 2016-11-16 03:04:21]

The CQ bit was unchecked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2016-11-16 03:04:38]

The CQ bit was checked by aelias@chromium.org

[commit-bot: I haz the power, 2016-11-16 03:05:09]

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

[aelias_OOO_until_Jul13, 2016-11-16 03:28:47]

The CQ bit was unchecked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2016-11-16 03:44:30]

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

[commit-bot: I haz the power, 2016-11-16 03:45:22]

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

[aelias_OOO_until_Jul13, 2016-11-16 04:05:31]

The CQ bit was unchecked by aelias@chromium.org

[aelias_OOO_until_Jul13, 2016-11-16 04:05:37]

The CQ bit was checked by aelias@chromium.org

[commit-bot: I haz the power, 2016-11-16 04:05:45]

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, 2016-11-16 06:48:57]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-11-16 06:52:07]

Description was changed from

==========
Fix three causes of blank thumbnails [2nd land]

All three of these fixes are required to address the devil case
http://crbug.com/659459, and some of them also help with some of the
other flickers.

1. In onPageLoadStarted, the URL can be the same as before, in
particular because history-item scroll offset restores count as load
starts.  These history restores often fire late in page load, *after*
the thumbnail was taken, leading to immediately throwing out the
thumbnail we just took earlier in page load.  Switch to the "invalidate"
path which only ejects the thumbnail if the URL changed.

2. In CacheTab, which is often called just to refresh the thumbnail with
the latest state, if readback is currently impossible, we used to remove
the old thumbnail.  Keep it instead.

3. Switch to the more reliable Surfaces-based mechanism for readback.
The layer-based mechanism often outputs black screenshots in difficult
racy cases like onStop readbacks.  The Surface-based mechanism had been
reverted because it tickles a driver bug on Nexus 7 2013 that itself causes
some flickers, but I verified that the repro scenario for that is quite
niche, and even on Nexus 7 it's probably less severe than the black
screenshot problem this fixes.

TBR=tedchoc@chromium.org
BUG=636630,640561,659459,646336
==========

to

==========
Fix three causes of blank thumbnails [2nd land]

All three of these fixes are required to address the devil case
http://crbug.com/659459, and some of them also help with some of the
other flickers.

1. In onPageLoadStarted, the URL can be the same as before, in
particular because history-item scroll offset restores count as load
starts.  These history restores often fire late in page load, *after*
the thumbnail was taken, leading to immediately throwing out the
thumbnail we just took earlier in page load.  Switch to the "invalidate"
path which only ejects the thumbnail if the URL changed.

2. In CacheTab, which is often called just to refresh the thumbnail with
the latest state, if readback is currently impossible, we used to remove
the old thumbnail.  Keep it instead.

3. Switch to the more reliable Surfaces-based mechanism for readback.
The layer-based mechanism often outputs black screenshots in difficult
racy cases like onStop readbacks.  The Surface-based mechanism had been
reverted because it tickles a driver bug on Nexus 7 2013 that itself causes
some flickers, but I verified that the repro scenario for that is quite
niche, and even on Nexus 7 it's probably less severe than the black
screenshot problem this fixes.

TBR=tedchoc@chromium.org
BUG=636630,640561,659459,646336

Committed: https://crrev.com/d9c930e47745312f5cc8a5b9d4e6802c18f8b5de
Cr-Commit-Position: refs/heads/master@{#432411}
==========

[commit-bot: I haz the power, 2016-11-16 06:52:08]

Patchset 2 (id:??) landed as
https://crrev.com/d9c930e47745312f5cc8a5b9d4e6802c18f8b5de
Cr-Commit-Position: refs/heads/master@{#432411}