I've just tried this locally and it works for me. The recorded trace does not look like one produced by DevTools -- was it obtained via lighthouse?

Thanks for responding so fast. Are you capturing a trace from your android device?

Yes. I wonder if in your scenario the inspected tab is actually active and visible -- for example, when you're not recording timeline, can you see screen cast updates on the left?

I have an open screen on my android chrome. I added a trace from desktop & android with just devtools + added a screenshot as well

Deleted: shop-polymer-desktop.json 24.5 MB

shop-polymer-desktop.json 24.5 MB Download

Deleted: shop-polymer-android.json 4.0 MB

shop-polymer-android.json 4.0 MB View Download

Deleted: Schermafdruk 2017-01-17 23.30.48.png 785 KB

	Schermafdruk 2017-01-17 23.30.48.png 785 KB View Download

Thanks, I've been able to reproduce this. FWIW, this seems to only happen during reload.

any news? on this issue :)

I tracked this down to callback passed to RenderWidgetHostViewAndroid::CopyFromCompositingSurface() being invoked with READBACK_FAILED. This appears to happen from within Surface::ClearCopyRequests() when it's invoked when a pending frame is being activated from within Surface::QueueFrame().
Adding some CC folks in a hope they would be able to help with that.

Some notes on reproducing this:
- some request get through successfully, but the majority is lost;
- reproduces well on stable and on ToT;
- you can either record timeline with screenshots or just open remote DevTools and observe that the screencast pane on the left is nor promptly updated most of the time when you scroll;
- does not seem to ever happen on desktop (linux), even with forced GPU rasterization.

Thanks for triaging this. I don't know who from the Chrome GPU team is best to help investigate. I'm pretty sure the GPU bots use this code path, though not as stressfully as the timeline view, and the pixel tests are running pretty reliably there. (See the Android bots on https://build.chromium.org/p/chromium.gpu.fyi .)

I see you mentioned pending frames getting activated. Note that surface dependency tracking has not yet been turned on in Chrome (I just finished landing the first set of patches this week). I don't think surface dependency tracking / surface synchronization has any influence on this. +danakj@ who knows more about copy requests.

Yeah, currently we attach the copy request to the root pass of the current frame in the surface, so if the timing's wrong a new frame could be given from the renderer before the surface is aggregated and the copy request is executed.

We could try saving CopyOutputRequests separately so that the can live across frames.

So would anyone be able to take care of this reasonably soon? A couple of rather important DevTools features depend on it and since a bunch of tests also depends on getting the screenshots, I guess this may contribute to overall flakiness and mask other problems, as already happened in the past.

The clearing behaviour has been there since https://chromium.googlesource.com/chromium/src/+/2cd9f8f5c3acf503ade180a5584a2c5c1e1004e1

I don't see anything in the CL description explaining the intention. Shall we just not clear from QueueFrame?

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

commit 37b0e1379938325304eeaff6afb9e7cb9f8bb618
Author: jbauman <jbauman@chromium.org>
Date: Wed Mar 01 03:04:30 2017

Don't delete CopyOutputRequests when queueing a new Surface frame.

This reduces the risk that the CopyOutputRequests will be discarded
unnecessarily. This only affects CopyOutputRequests created through
SurfaceFactory::RequestCopyOfSurface, as requests submitted on
RenderPasses directly with the frame will still be discarded.

BUG= 681988 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/37b0e1379938325304eeaff6afb9e7cb9f8bb618/cc/surfaces/surface.cc
[modify] https://crrev.com/37b0e1379938325304eeaff6afb9e7cb9f8bb618/cc/surfaces/surface_unittest.cc

Cool, works for me now -- thanks a lot!

on which chrome (dev, beta, canary, ...) can I test this? :)

Chrome canary but after canary is updated again. Hopefully in 12 hours.