Blocking this on  Issue 608576  since the performance test will be added under that bug.

What's the status here now that 608576 is resolved?

bajones@ Any luck here?

I'll take this from Brandon.

https://codereview.chromium.org/1947763002/ was the work-in-progress.

Kai, could you take on the investigation of this bug? We need to start with Brandon's old patch and see why it was failing the printing layout tests.

I have a passing version of the patch here:

https://codereview.chromium.org/2510583004/

I haven't seen any performance changes (tested teapots demo from 638085, as well as animometer), but I haven't yet run any profiling.

FTR, that patch landed but didn't post a message in this bug, for some reason.
https://codereview.chromium.org/2510583004

Leaving open at least until we figure out whether it had an effect. I've started some work on profiling it and will post results here.

Thanks Kai for updating. I also found that comments aren't being applied to bugs when CLs land and filed Issue 670756 about it.

On my desktop it turns out the Animometer is now GPU-process bound (which used to not be true), hence no difference in the framerate.

For the following benchmark, I was able to measure some performance differences in about:tracing.
http://browserbench.org/MotionMark/developer.html?test-interval=30&display=minimal&tiles=big&controller=fixed&frame-rate=50&kalman-process-error=1&kalman-measurement-error=4&time-measurement=performance&suite-name=3DGraphics&test-name=WebGL&complexity=5000

Without patch: avg time in v8::Execute: 8.712 ms
With    patch: avg time in v8::Execute: 7.494 ms

For the aquarium demo
http://webglsamples.org/aquarium/aquarium.html
cranked up to 10,000 fish, I _may_ have seen a small performance improvement (roughly 50 -> 53 FPS), but the variance is very high so it's hard to measure.

I haven't yet managed to run profiling that can see anything in markContextChanged, though.

Thanks for following up Kai. Good investigation.

If it seems like we're facing diminishing returns in this investigation please feel free to close this as fixed.

I'd like to at least have a concrete result for the actual performance of markContextChanged before closing it. It shouldn't be that hard but I need to figure out how to get a more detailed profile. (Victor mentioned setting enable_profiling = true.)

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

commit 5f8b467781b1b08d611e1d05f31c10dee5538edb
Author: capn <capn@chromium.org>
Date: Mon Apr 03 21:16:06 2017

Fix non-anti-aliased frame update.

m_contentsCangeCommitted (now renamed to m_contentsChangeResolved) was
not getting set on non-anti-aliased DrawingBuffers, causing us to always
skip setting m_animationFrameInProgress to true. This in turn skips
calling glReadPixels() for CPU-composited frames.

BUG= 707298 , 608873 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/5f8b467781b1b08d611e1d05f31c10dee5538edb/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/5f8b467781b1b08d611e1d05f31c10dee5538edb/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h

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

commit 3c777beab66117a31006f039de191c9a9dccefc7
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Apr 14 23:04:29 2017

Fix non-anti-aliased frame update.

m_contentsCangeCommitted (now renamed to m_contentsChangeResolved) was
not getting set on non-anti-aliased DrawingBuffers, causing us to always
skip setting m_animationFrameInProgress to true. This in turn skips
calling glReadPixels() for CPU-composited frames.

BUG= 707298 , 608873 
TBR=kbr@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2793653002
Cr-Commit-Position: refs/heads/master@{#461542}
(cherry picked from commit 5f8b467781b1b08d611e1d05f31c10dee5538edb)

Review-Url: https://codereview.chromium.org/2810333009 .
Cr-Commit-Position: refs/branch-heads/3029@{#724}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/3c777beab66117a31006f039de191c9a9dccefc7/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/3c777beab66117a31006f039de191c9a9dccefc7/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h

Finally came back to this and did some profiling with a Chrome profiling build. I ran Animometer for about 1 minute with and without my patch (#10). Results seem good:
                                              | unpatched     | patched
WebGLRenderingContextBase::MarkContextChanged | 0.44% / 0.52% | not in profile
WebGLRenderingContextBase::drawArrays         | 0.46% / 4.36% | 0.62% / 3.21%

(First number is in the function, second number is in the function and its children, I think.)

Great Kai! Thanks for pushing this over the finish line.