cc: Remove and Create the correct tiles when resizing live tiles rect

Committed: https://crrev.com/e3b7da9e87ee035c2c4529ccbfe541a7ffebd077
Cr-Commit-Position: refs/heads/master@{#292417}

[danakj, 2014-08-26 00:53:53]

Oh I'll have to improve this, there's some issues still.

[danakj, 2014-08-26 02:14:04]

I found that using a DifferenceIterator with a bool to not include borders made
the most sense to me once I worked out all the cases that needed to be handled.

[danakj, 2014-08-26 02:14:33]

PTAL added some more tests for PictureLayerTiling, and a bunch of tests for
DifferenceIterator

[enne (OOO), 2014-08-26 18:43:24]

Do we ever need include_borders = true?

[danakj, 2014-08-26 18:49:40]

On 2014/08/26 18:43:24, enne wrote:
> Do we ever need include_borders = true?

Yes, I added comments in the places where it's true about why. Tell me if you
disagree with them though.

[vmpstr, 2014-08-26 18:55:42]

Can you please include the test from https://codereview.chromium.org/507463002
with this patch as well?

[enne (OOO), 2014-08-26 18:56:45]

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling.cc:508: bool include_borders = true;
I guess really it's a question of why we include borders when prioritizing
visible tiles.  If a tile's non-border pixels are not in the visible rect, that
tile is not going to get drawn.  It seems like this is wrong, and if this flips,
then the other uses below of include_borders should also flip (I think).

[enne (OOO), 2014-08-26 18:57:14]

(And yes, I was the one who added the original code that included borders and
the refactoring that had an explicit include_borders=true variable, but as I
stare at it, it doesn't make much sense to me.)

[danakj, 2014-08-26 19:00:11]

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:244:
SetLiveRectAndVerifyTiles(gfx::Rect(right + 1, bottom + 1));
This is the test from https://codereview.chromium.org/507463002. It will crash
in here recreating these tiles without this change. Do you think that test adds
something beyond this?

[vmpstr, 2014-08-26 19:02:15]

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:244:
SetLiveRectAndVerifyTiles(gfx::Rect(right + 1, bottom + 1));
On 2014/08/26 19:00:11, danakj wrote:
> This is the test from https://codereview.chromium.org/507463002. It will crash
> in here recreating these tiles without this change. Do you think that test
adds
> something beyond this?

Ah ok. No this is fine, it's just I couldn't reproduce with SetLiveTileRects
only and had to resort to UpdateTilesToCurrentPile. But if this fails as well,
then that's good enough.

[danakj, 2014-08-26 19:28:34]

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:244:
SetLiveRectAndVerifyTiles(gfx::Rect(right + 1, bottom + 1));
On 2014/08/26 19:02:15, vmpstr wrote:
> On 2014/08/26 19:00:11, danakj wrote:
> > This is the test from https://codereview.chromium.org/507463002. It will
crash
> > in here recreating these tiles without this change. Do you think that test
> adds
> > something beyond this?
> 
> Ah ok. No this is fine, it's just I couldn't reproduce with SetLiveTileRects
> only and had to resort to UpdateTilesToCurrentPile. But if this fails as well,
> then that's good enough.

Oh, I lied slightly. It doesn't crash in here. But the EXPECTations of this test
do cover the same cases, as I'll explain.

The test in https://codereview.chromium.org/507463002 shrank the live rect to a
tile boundary by shrinking the size of the tiling. Then it grew the tiling
again, without changing the live rect. It crashed because this growth included
tiles outside the live rect. (Then later increasing the live rect size caused us
to make the tiles a 2nd time so boom.)

This test shrinks the live rect to a tile boundary, but not by resizing the
tiling. This allows us to check with EXPECT that the tiles were removed (and not
recreated).

[danakj, 2014-08-26 19:29:35]

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/20001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling.cc:508: bool include_borders = true;
On 2014/08/26 18:56:45, enne wrote:
> I guess really it's a question of why we include borders when prioritizing
> visible tiles.  If a tile's non-border pixels are not in the visible rect,
that
> tile is not going to get drawn.  It seems like this is wrong, and if this
flips,
> then the other uses below of include_borders should also flip (I think).

Ok I am happy to make this false everywhere then. I agree doing it to all the
places below is correct.

[danakj, 2014-08-26 20:13:59]

PTAL

[danakj, 2014-08-26 20:15:18]

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:612: int borders =
tiling->TilingDataForTesting().border_texels();
This test is the only one affected by the include_borders = false in PLT change.

[enne (OOO), 2014-08-26 20:20:27]

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:614:
tile_content_rect_inside_borders.Inset(borders, borders);
This is not correct for edge tiles.  You should ask the TilingDataForTesting for
the TileBounds(i, j).

[danakj, 2014-08-26 20:28:47]

Fixed (did not effect the test) PTAL

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling_unittest.cc (right):

https://codereview.chromium.org/505913003/diff/40001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling_unittest.cc:614:
tile_content_rect_inside_borders.Inset(borders, borders);
On 2014/08/26 20:20:27, enne wrote:
> This is not correct for edge tiles.  You should ask the TilingDataForTesting
for
> the TileBounds(i, j).

oh right i was trying to go thru Tile* but no need.

[enne (OOO), 2014-08-26 20:33:48]

lgtm, thanks!

[vmpstr, 2014-08-26 20:52:34]

https://codereview.chromium.org/505913003/diff/60001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/60001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling.cc:942: true /* include_borders */);
Can you fix this up as well, while here? The iterators should mimic whatever
UpdateTilePriorities is currently doing. This might also mean changing
SpiralDifferenceIterator to do what the DifferenceIterator is now doing.

[danakj, 2014-08-26 20:57:06]

https://codereview.chromium.org/505913003/diff/60001/cc/resources/picture_lay...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/60001/cc/resources/picture_lay...
cc/resources/picture_layer_tiling.cc:942: true /* include_borders */);
On 2014/08/26 20:52:33, vmpstr wrote:
> Can you fix this up as well, while here? The iterators should mimic whatever
> UpdateTilePriorities is currently doing. This might also mean changing
> SpiralDifferenceIterator to do what the DifferenceIterator is now doing.

Done! PTAL

[danakj, 2014-08-26 21:45:01]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2014-08-26 21:46:39]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/danakj@chromium.org/505913003/80001

[commit-bot: I haz the power, 2014-08-26 22:58:24]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)
  mac_gpu_retina_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu_retina_tr...)
  mac_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu_triggered...)
  win_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu_triggered...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-26 23:24:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-08-26 23:24:13]

Try jobs failed on following builders:
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)
  mac_gpu_retina_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu_retina_tr...)

[danakj, 2014-08-27 03:18:39]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2014-08-27 03:19:52]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/danakj@chromium.org/505913003/80001

[commit-bot: I haz the power, 2014-08-27 04:40:07]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)
  mac_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu_triggered...)
  win_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu_triggered...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-27 04:46:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-08-27 04:46:33]

Try jobs failed on following builders:
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Ken Russell (switch to Gerrit), 2014-08-27 08:29:50]

On 2014/08/27 04:40:07, I haz the power (commit-bot) wrote:
> FYI, CQ is re-trying this CL (attempt #1).
> The failing builders are:
>   linux_gpu_triggered_tests on tryserver.chromium.gpu
>
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)
>   mac_gpu_triggered_tests on tryserver.chromium.gpu
>
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu_triggered...)
>   win_gpu_triggered_tests on tryserver.chromium.gpu
>
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu_triggered...)
>   win_chromium_rel_swarming on tryserver.chromium.win
>
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
>   win_chromium_x64_rel_swarming on tryserver.chromium.win
>
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

The win_gpu_triggered_tests failures (at least) are real and caused by this
patch. Here is a stack trace:

TabCrashException: Tab crashed
Stack Trace:
********************************************************************************
ChildEBP RetAddr
0504d98c 6559ec68 chrome_child!base::debug::BreakDebugger+0x10
0504d994 65635e65 chrome_child!`anonymous
namespace'::SilentRuntimeAssertHandler+0x8
0504dde4 670b93a9 chrome_child!logging::LogMessage::~LogMessage+0x1f5
0504dee8 670ba27a chrome_child!cc::PictureLayerTiling::CreateTile+0x79
0504e03c 670ba7e3 chrome_child!cc::PictureLayerTiling::SetLiveTilesRect+0x27a
0504e24c 6706aa28
chrome_child!cc::PictureLayerTiling::UpdateTilePriorities+0x323
0504e508 6706ae6e chrome_child!cc::PictureLayerImpl::UpdateTilePriorities+0x2c8
0504ea28 6702fe7e chrome_child!cc::PictureLayerImpl::UpdateTiles+0x3ee
0504ec14 670251e6 chrome_child!cc::LayerTreeImpl::UpdateDrawProperties+0x46e
0504ec48 6704f152 chrome_child!cc::LayerTreeHostImpl::CommitComplete+0xd6
0504f634 670acfc8 chrome_child!cc::ThreadProxy::ScheduledActionCommit+0x5e2
0504f740 670aca74 chrome_child!cc::Scheduler::ProcessScheduledActions+0x158
0504f774 6704de7c chrome_child!cc::Scheduler::NotifyReadyToCommit+0xa4
0504f838 655a954f
chrome_child!cc::ThreadProxy::ReadyToFinalizeTextureUpdates+0xac
0504f848 65661ac6
chrome_child!base::internal::Invoker<1,base::internal::BindState<base::internal::RunnableAdapter<void
(__thiscall base::CancelableCallback<void __cdecl(void)>::*)(void)>,void
__cdecl(base::CancelableCallback<void __cdecl(void)> *),void
__cdecl(base::WeakPtr<base::CancelableCallback<void __cdecl(void)> >)>,void
__cdecl(base::CancelableCallback<void __cdecl(void)> *)>::Run+0x2f
0504f8e0 6563ac85 chrome_child!base::debug::TaskAnnotator::RunTask+0x1b6
0504f9d0 65639fdd chrome_child!base::MessageLoop::RunTask+0x295
0504fa64 65663aab chrome_child!base::MessageLoop::DoWork+0x1cd
0504fb3c 6563a9e9 chrome_child!base::MessagePumpDefault::Run+0x12b
0504fc04 656646b3 chrome_child!base::MessageLoop::RunHandler+0x89
0504fc0c 6563a946 chrome_child!base::RunLoop::Run+0x13
0504fc30 656460bb chrome_child!base::MessageLoop::Run+0x16
0504fc38 656465a7 chrome_child!base::Thread::Run+0xb
0504fd0c 656511fa chrome_child!base::Thread::ThreadMain+0x167
0504fd28 7515338a chrome_child!base::`anonymous namespace'::ThreadFunc+0xaa
WARNING: Stack unwind information not available. Following frames may be wrong.
0504fd34 7764bf32 kernel32!BaseThreadInitThunk+0x12
0504fd74 7764bf05 ntdll!RtlInitializeExceptionChain+0x63
0504fd8c 00000000 ntdll!RtlInitializeExceptionChain+0x36

From
http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu_triggered...
.

[danakj, 2014-08-27 17:24:56]

PTAL. This should fix all possible double CreateTiles based on the live tiles
rect or tiling changing bounds. Verified all the test cases in the bug no longer
assert.

For the changes in the latest patchset, the test coverage is:
- ResizeOverBorderPixelsDeletesTiles covers the change in PLT::DoInvalidate()
- CreateMissingTilesStaysInsideLiveRect covers the change in
PLT::CreateMissingTilesInLiveTilesRect()
- ResizeTilingOverTileBorders covers the change in
PLT::UpdateTilesToCurrentPile().

[danakj, 2014-08-27 17:53:56]

Yay this stopped crashing in the webgl tests too.

[danakj, 2014-08-27 18:06:42]

https://codereview.chromium.org/505913003/diff/120001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/120001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:446: bool
PictureLayerTiling::RemoveTileAt(int i,
Oh, this bears mentioning. While I was at it and removing tiles, I noticed only
one place that removed tiles actually went to the recycled_twin.. so I fixed
that by making all the places that do erase() instead do RemoveTileAt(). Maybe I
should do this separately, but I didn't wanna add more places that didn't remove
from the recycled layer either?

[vmpstr, 2014-08-27 19:13:21]

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:189:
live_tiles_rect_.Intersect(content_rect);
nit: Put a comment here saying that this is the place where you actually shrink
live tiles rect/tiling data. Otherwise it's kind of easy to skim over it without
noticing

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:201: // There is no recycled twin since
this is run on the pending tiling.
Please DCHECK the tree

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:210: for (int i = before_left; i <=
before_right; ++i) {
nit: this can be after_right, I think? Otherwise you're clearing the corner
twice? Maybe?

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:217: for (int i = before_right + 1; i <=
after_right; ++i) {
Can you please add a comment in the style of

// ------===
// |    |xx|
// |    |xx|
// ------===

or something where X denotes the spot that this loop touches, etc? I'm not sure
if ascii art is the way to go here, but I think it should clarify what is going
on. I'm just looking at the indecies and trying to visualize the area being
iterated.

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:280: // There is no recycled twin since
this is run on the pending tiling.
nit: I think we have a client_->GetTree in this version, can you sprinkle a few
dchecks where you expect this to be run on the pending tree only

[danakj, 2014-08-27 19:27:01]

Thanks! PTAL

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:189:
live_tiles_rect_.Intersect(content_rect);
On 2014/08/27 19:13:21, vmpstr wrote:
> nit: Put a comment here saying that this is the place where you actually
shrink
> live tiles rect/tiling data. Otherwise it's kind of easy to skim over it
without
> noticing

Done.

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:201: // There is no recycled twin since
this is run on the pending tiling.
On 2014/08/27 19:13:21, vmpstr wrote:
> Please DCHECK the tree

Oh, GetTree, I missed that in the client. Done.

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:210: for (int i = before_left; i <=
before_right; ++i) {
On 2014/08/27 19:13:21, vmpstr wrote:
> nit: this can be after_right, I think? Otherwise you're clearing the corner
> twice? Maybe?

Oh, yah. I think so.

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:217: for (int i = before_right + 1; i <=
after_right; ++i) {
On 2014/08/27 19:13:21, vmpstr wrote:
> Can you please add a comment in the style of
> 
> // ------===
> // |    |xx|
> // |    |xx|
> // ------===
> 
> or something where X denotes the spot that this loop touches, etc? I'm not
sure
> if ascii art is the way to go here, but I think it should clarify what is
going
> on. I'm just looking at the indecies and trying to visualize the area being
> iterated.

I changed these from a double for-loop to an if statement + dcheck + single for
loop. Does that help? Do you still want a verbose comment?

https://codereview.chromium.org/505913003/diff/180001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:280: // There is no recycled twin since
this is run on the pending tiling.
On 2014/08/27 19:13:21, vmpstr wrote:
> nit: I think we have a client_->GetTree in this version, can you sprinkle a
few
> dchecks where you expect this to be run on the pending tree only

Done.

[vmpstr, 2014-08-27 19:30:45]

https://codereview.chromium.org/505913003/diff/220001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/220001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:222: DCHECK_EQ(after_right, before_right +
1);
That looks good, but is it true? Why? Can't a layer grow by a bunch? If it is
true, can you please put a comment explaining?

[danakj, 2014-08-27 19:35:12]

https://codereview.chromium.org/505913003/diff/220001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/220001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:222: DCHECK_EQ(after_right, before_right +
1);
On 2014/08/27 19:30:45, vmpstr wrote:
> That looks good, but is it true? Why? Can't a layer grow by a bunch? If it is
> true, can you please put a comment explaining?

The layer can grow, but the live tiles rect doesn't change. This is only true
when a new tile appears on the edge of the current live tiles rect. I'll expand
the comment.

[danakj, 2014-08-27 19:36:17]

Moar comment PTAL

[danakj, 2014-08-27 20:01:45]

One of my DCHECKs is a lie it looks like, I'll look into it.

[danakj, 2014-08-27 21:02:34]

Ah, PictureLayerImpl::PushPropsTo calls tilings_->RemoveTilesInRegion() before
it sets the client on its own tilings_, which caused the tiling to think it was
active still. Fixed now.

[vmpstr, 2014-08-27 22:28:50]

lgtm

https://codereview.chromium.org/505913003/diff/240001/cc/resources/picture_la...
File cc/resources/picture_layer_tiling.cc (right):

https://codereview.chromium.org/505913003/diff/240001/cc/resources/picture_la...
cc/resources/picture_layer_tiling.cc:220: // and/or column of tiles may now
exist inside the same live_tiles_rect_.
Ah! That makes sense, thanks for the comment.

[danakj, 2014-08-28 18:15:10]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2014-08-28 18:16:30]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/danakj@chromium.org/505913003/280001

[danakj, 2014-08-28 18:19:55]

The last patchset passed all the bots and this is just a rebase, ran
cc_unittests locally. Trying to land manually.

[danakj, 2014-08-28 18:21:12]

Committed patchset #15 (id:280001) to pending queue manually as 944b1ce
(presubmit successful).

[commit-bot: I haz the power, 2014-09-10 03:00:42]

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