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
Review-Url: https://codereview.chromium.org/2503183003
Cr-Commit-Position: refs/heads/master@{#432411}
Committed: https://chromium.googlesource.com/chromium/src/+/b27a7d7a86cfdc06c04ab3728e08ff10f786b975

[aelias_OOO_until_Jul13, 2016-11-17 02:09:27]

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

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

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

Review-Url: https://codereview.chromium.org/2503183003
Cr-Commit-Position: refs/heads/master@{#432411}
Committed:
https://chromium.googlesource.com/chromium/src/+/b27a7d7a86cfdc06c04ab3728e08...
==========

[aelias_OOO_until_Jul13, 2016-11-17 02:09:28]

Committed patchset #2 (id:20001) manually as
b27a7d7a86cfdc06c04ab3728e08ff10f786b975.