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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_Lr0pAoM


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

chromium-rel-mac-hdd

This is WebGL Image Chromium. It was reverted but landed again, and the regression seems to have stuck.

erikchen, can you invested?

Yup, looking into it.

 Issue 622330  has been merged into this issue.

I ran through the stressful tests on a MBA with a Intel HD 5000, and saw minimal difference, or slight frame rate improvement for Chromium Image. This includes aquarium.

Looking at the Telemetry graphs, we see either no changes for more tests, or significant for some (aquarium), where frame times double! 

"chromium-rel-mac-hdd" gets mapped to "Mac HDD Perf", which in turn is mapped to the bots 'build24-b1', 'build25-b1', 'build26-b1', 'build27-b1', 'build28-b1'. 

I sshed into both build24 and build25. They both have the same graphics card.

chrome-bot@build24-b1:(Mac 10.10.5):~$ /usr/sbin/system_profiler SPDisplaysDataType
Graphics/Displays:

"""
    NVIDIA GeForce 320M:

      Chipset Model: NVIDIA GeForce 320M
      Type: GPU
      Bus: PCI
      VRAM (Total): 256 MB
      Vendor: NVIDIA (0x10de)
      Device ID: 0x08a4
      Revision ID: 0x00a2
      ROM Revision: 3546
      Displays:
        Raritan CIM:
          Resolution: 1024 x 768 @ 60 Hz
          Pixel Depth: 32-Bit Color (ARGB8888)
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Rotation: Supported
          Television: Yes
"""

The NVIDIA 320M is ancient, and I'm surprised it's still supported by Apple. If things are working OK on modern GPUs (say, Intel HD 4000 and later, and the current Retina MacBook Pros) then I would discount this regression -- and not revert all of Erik's work in response. I would also suggest that we put more modern hardware on the Perf waterfall.

I'm been playing around with a MBA, SSD, 320M. 2.13 GhZ INtel Core 2 Duo. 4GB ram. On this device, both the Image and non-Image paths draw aquarium at 30 fps. 

The specs on the lab bots are: 2.66 Ghz Core 2 Duo, 8 GB RAM.

If we could take one of the devices offline, I could play with it directly to see what's causing the regression. Unfortunately, I can't reproduce the regression locally.

Looking at other devices, there's not much shift except in chromium-rel-mac11. https://chromeperf.appspot.com/report?sid=220fc7bd7a1074610c4caeb6960600ef162ee330cdff793edbbb3b55b0dd99c6

Diving in, it looks like there's a regression to frame_time and mean_frame_time around 401788-401816. The CL closest to that time period is:
Add a call to DescheduleUntilFinishedCHROMIUM to WebGL.
https://codereview.chromium.org/2093533002/

I'm wondering if what we're seeing is actually an improvement in real performance, rather than the known-inaccurate fps as reported by the test case. The two tend to be inversely related (the faster the page thinks it's submitting work, the fewer frames are actually being drawn).

Stats on build58-a1 (chromium-rel-mac11)
"""
    Intel HD Graphics 4000:

      Chipset Model: Intel HD Graphics 4000
      Type: GPU
      Bus: Built-In
      VRAM (Dynamic, Max): 1536 MB
      Vendor: Intel (0x8086)
      Device ID: 0x0166
      Revision ID: 0x0009
      Displays:
        Smart Cable:
          Resolution: 1024 x 768 @ 75 Hz
          Pixel Depth: 32-Bit Color (ARGB8888)
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Rotation: Supported
          Adapter Type: Apple Mini DisplayPort To VGA Adapter
          Adapter Firmware Version: 1.03
"""

I got an Intel HD 4000 device to test on, and once again, see no performance difference between Image CHROMIUM and non-Image CHROMIUM paths. 

As I see it, either we can ignore these regressions, because we can't reproduce them, or we can take some of the telemetry machines offline so that I can directly debug on them.

Would it be okay to take one of the Mac HDD bisect/try bots? That'd be less disruptive than pulling the main waterfall ones. The machines are:

build31-b4
build32-b4
build33-b4

You can try running a perf try job with your CL locally reverted to see if it repros.

Running try job here: https://codereview.chromium.org/2095283003

Trying again: https://codereview.chromium.org/2100163002

+dtu, can you look at the compile failures on the first run? https://uberchromegw.corp.google.com/i/tryserver.chromium.perf/builders/mac_hdd_perf_bisect/builds/605/steps/compile%20(with%20patch)/logs/stdio

http://storage.googleapis.com/chromium-telemetry/html-results/results-2016-06-27_13-25-27

We're seeing a 6-7% regression in frame time on the try-bots, so not as pronounced as a 19.8% regression, but still present. Is there a documented process for taking down/bring-back-up a try bot? 

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This has recovered, marking WontFix.