We performed a study in May 2016 to see how adb screenrecord affects page load
performance on a wikipedia page, and First Contentful Paint (FCP) in particular.

A by-product of the study is a few assets:

1. a histogram of FCP for 240 page loads

attached: wikipedia_fcp_time.png

A few "Good" outliers are visible: painting a few seconds earlier than usual -
it would be good to always paint it that early!!

2. two traces (more available upon request) corresponding to the two behaviors

attached: trace-17-outlier.json.gz
attached: trace-18-normal.json.gz

3. a side-by-side recorded video proving that the early paint was in fact
   user-visible

attached: ttfcp_outlier_vs_regular.mp4

4. ksakamoto@ performed an initial analysis on this scehduling issue and
   provided two screenshots of traces.

attached: outlier.png
attached: normal.png

I am not sure these correspond to the exact traces I provide, could choose
slightly different traces.

=== begin analysis by ksakamoto ================================================
I think this is not a bug of trace processing, but first contentful paint
actually happened very early in these runs.

Outlier case (see attached outlier.png):

1. The first batch of HTML chunks from HTMLParserThread are processed
2. Stylesheet is loaded and parsed. Rendering is unblocked here
3. The first frame is rendered (the long vertical line is FCP)
4. The rest of parsed HTML chunks are processed
5. After a long layout, the second frame is rendered

Normal case (see attached normal.png):

1. The first batch of HTML chunks from HTMLParserThread are processed
2. Stylesheet is loaded and parsed. Rendering is unblocked here
3. The rest of parsed HTML chunks are processed
4. After a long layout, the first frame is rendered

So this looks like a race between HTML parser and BeginMainFrame. If
BeginMainFrame hits the sweet spot between the stylesheet parse and
processParsedChunkFromBackgroundParser, first frame is rendered with partial
document. Otherwise, first frame is not rendered until document is fully parsed
and laid out, which takes ~3 seconds.
===== end analysis by ksakamoto ================================================

Then more discussion followed:

=== begin feedback by pmeenan ==================================================
The parser yielding to allow paints is super-racy (more so when we switched and
tied everything to vsync).  It basically posts a task back to itself so if a
paint/layout/vsync/whatever task happened to be waiting in the task queue it
would get a chance to run before the parser would continue and potentially do
some heavy work.  To deterministically allow a paint to happen we probably need
a construct from the scheduler to allow us to post a task to run after the
processing for the next vsync is complete.  That would potentially introduce up
to a 16ms pause every time the yield is done though so we'd want to be a lot
more intelligent about it than we are currently (like only do it if layout is
needed and TTFCP hasn't happened yet).
===== end feedback by pmeenan ==================================================

=== begin response by skyostil =================================================
The Blink scheduler has the ability to prioritize rendering vs. loading work. If
it could get some kind of signal saying that now would be a good time to get the
first frame on the screen, I think we could hit the earlier case more reliably.
That could also help avoid unnecessary repaints during loading.
===== end response by skyostil =================================================

 

Deleted: wikipedia_fcp_time.png 10.6 KB

	wikipedia_fcp_time.png 10.6 KB View Download

Deleted: trace-18-normal.json.gz 1.2 MB

trace-18-normal.json.gz 1.2 MB Download

Deleted: trace-17-outlier.json.gz 1.3 MB

trace-17-outlier.json.gz 1.3 MB Download

Deleted: ttfcp_outlier_vs_regular.mp4 195 KB

	ttfcp_outlier_vs_regular.mp4 195 KB View Download

Deleted: normal.png 276 KB

	normal.png 276 KB View Download

Deleted: outlier.png 290 KB

	outlier.png 290 KB View Download