All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=768553

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=30bfda05dbff5bca3e39576404e0e6db01d8cf678d4ba7984206db7920d51ce5


Bot(s) for this bug's original alert(s):

chromium-rel-mac11-air

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14fde9d4780000

📍 Pinpoint job completed.
https://pinpoint-dot-chromeperf.appspot.com/job/14fde9d4780000

Found significant differences after 1 commit:

avoid thread-jump in multibuffer_datasource::read()
By hubbe@google.com · Fri Sep 22 21:11:16 2017
chromium@ff3b31782d552b03104a6d831c7530605b52b13f

hubbe: can you take a look? See #3

assigning to hubbe for real, see #3

Not sure yet, but I suspect that this is working as intended.
This test makes the render thread very busy, which I think is causing the video to play slower than it's supposed to. My change essentially removes this limitation, which lets the video play correctly, but takes away some cpu and gpu time from the rendering thread where the benchmark is running.

Stupid question: How do I run this test?

+junov: benchmark owner: do you think hubbe@'s change justify the 17% regression?

hubbe@: to run the benchmark:

src/tools/perf/run_benchmark blink_perf.canvas --browser<...>

To really see what is going on, try changing the test to run 100 iterations.
You can turn my change off by changing media/blink/multibuffer_data_source.cc:358 from:
  if(reader_) {
to:
  if (0) {

With the change off, the video hangs repeatedly as the test is running. With my change on, the video keeps playing smoothly. This isn't actually affecting the speed of subtextures, but it is affecting this benchmark.

Marking as WontFix.