That's interesting. I would think that alpha:false should always be the same speed or faster, since blending can be disabled.

Do you see the same performance difference in Chrome Canary?

If so, is there any change with the command line flag:
  --disable-webgl-image-chromium
e.g.:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/t1 --disable-webgl-image-chromium

Seem to get the same behaviour in Canary. When run as normal and when run with your command line.

My experience is actually the opposite.  When running in the "dynamic" mode, with alpha=true, it's really janky, we lose a lot of frames, so the reported fps is way off; with alpha=false, it's actually smooth, although the reported fps is lower. I tested on MacBook Air 13inch Mid 2013 with Intel HD 5000 GPU.

Thank you for providing more feedback. Adding requester "ashejole@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

I've compared the following three browsers:

Firefox Nightly 49.0a1 (2016-05-02)
Safari 9.1 (11601.5.17.1)
Chrome 52.0.2722.0 (Official Build) canary (64-bit)

on the same hardware (MacBook Air (13-inch, Mid 2013), Intel HD Graphics 5000, OS X 10.11.4).

I do see a performance discrepancy:

              alpha=true         alpha=false
Firefox         smooth             smooth
Safari          janky              janky
Chrome          smooth             janky

It's interesting that Safari's somewhat janky in both the alpha=true and alpha=false scenarios, and that Firefox is smooth in all cases.

I suspect what's going on is that this content is on the verge of being GPU-bound on this particular hardware, and that the browsers which are using Core Animation for their presentation are dropping frames inside CA, which is a behavior that was just diagnosed and worked on in  Issue 601608 .

Chris, does this sound like the same problem to you?

Note: I tried inserting the glFinish in the attached patch, just before the mailbox is produced. The alpha=false version is still slower than the alpha=true version on both the MacBook Air with Intel HD 5000 above, and my MacBook Pro Retina with NVIDIA GPU. If that would be sufficient to introduce back-pressure to the code path which renders WebGL into GLImages then it doesn't seem to have the desired effect.

Deleted: finish.patch 781 bytes

finish.patch 781 bytes Download

That sounds like a possibility.

Running with --show-mac-overlay-borders will show which renderer you are using (CoreAnimation versus OpenGL). If the screen has pink/grey regular borders, it's CoreAnimation. If it's red/green borders, it's OpenGL.

It may be that alpha=false is hitting one path while alpha=true is hitting another (see  issue 595948 ).

Right now, alpha=true content should be using IOSurfaces, and alpha=false should be using normal textures.

Aha!! Thanks Chris. Yes, it looks like the alpha=true case is using CA, while alpha=false is using OpenGL.

Let's discuss more in person tomorrow.

After discussion with ccameron@ and erikchen@ I patched in erikchen's https://codereview.chromium.org/1856933002/ , which makes alpha:false WebGL contexts go through the same compositing path as alpha:true contexts.

Paradoxically, this makes the alpha:false case go slower. I think it might have to do with the intermediate framebuffer blit, and possibly the fact that the final destination is still an RGB format texture.

The current hypothesis is that rendering to and possibly texturing from RGB format textures is very slow on Intel GPUs, or maybe just on OS X on Intel GPUs.

Continuing to investigate.

The problem is the use of GL_RGB format textures. Even when continuing to do the intermediate blit in https://codereview.chromium.org/1856933002/ , but making the destination texture GL_RGBA, the alpha:false content speeds up tremendously, and appears to be about the same speed as alpha:true.

erikchen@ sat down with me and pointed out that my analysis was wrong; the problem is that GL_RGB8 multisampled renderbuffers perform poorly. Allocating it with GL_RGBA8 internal format speeds up the content significantly.

Erik volunteered to prepare a follow-on CL tomorrow which will be a simplification and eliminate the intermediate blit. Reassigning.

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

commit 9ddf8ea36a7ddf52bd3fcc23f5684abe04ae2778
Author: erikchen <erikchen@chromium.org>
Date: Thu May 05 09:09:56 2016

Clean up DrawingBuffer.

This CL is a refactor and should have no functional effect.

Changes in this CL:
1. The constructor of DrawingBuffer now takes wantDepth and wantStencil
arguments. These parameters, which never change, no longer need to be passed to
Initialize() or reset().
2. Renamed requiresRGBEmulation() -> requiresAlphaMask. Renamed
attachColorBufferToCurrentFBO() -> attachColorBufferToReadFramebuffer().
3. Added documentation.
4. Moved member initialization into the header file.
5. There used to be multiple methods named resize*, some of which were
incorrectly named, and some of which had odd dependencies on each other. The
methods resizeMultisampleFramebuffer() and resizeDepthStencil() now have no
external dependencies. There is a new method resizeDefaultFramebuffer() which
resizes all buffers attached to the default framebuffer, and all associated
framebuffers.

BUG= 607130 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/9ddf8ea36a7ddf52bd3fcc23f5684abe04ae2778/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/9ddf8ea36a7ddf52bd3fcc23f5684abe04ae2778/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/9ddf8ea36a7ddf52bd3fcc23f5684abe04ae2778/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/9ddf8ea36a7ddf52bd3fcc23f5684abe04ae2778/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferTest.cpp

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

commit 04a443352b363a4fdecee6c243ff5c02566a6795
Author: erikchen <erikchen@chromium.org>
Date: Thu May 05 09:16:57 2016

Add plumbing for two gpu workarounds, soon to be used by DrawingBuffer.

The workaround disable_multisample_renderbuffer_color_mask is needed because
glColorMask does not work for multisample renderbuffers on old AMD GPUs.

The workaround disable_rgb_multisample_renderbuffer is needed because
multisample renderbuffers with format GL_RGB8 have performance issues on Intel
GPUs.

BUG= 595948 ,  607130 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/04a443352b363a4fdecee6c243ff5c02566a6795/gpu/command_buffer/common/capabilities.h
[modify] https://crrev.com/04a443352b363a4fdecee6c243ff5c02566a6795/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/04a443352b363a4fdecee6c243ff5c02566a6795/gpu/config/gpu_driver_bug_list_json.cc
[modify] https://crrev.com/04a443352b363a4fdecee6c243ff5c02566a6795/gpu/config/gpu_driver_bug_workaround_type.h
[modify] https://crrev.com/04a443352b363a4fdecee6c243ff5c02566a6795/gpu/ipc/common/gpu_command_buffer_traits_multi.h

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

commit fc773b807b0d136aa17e2ac18a55bdd2810118bc
Author: erikchen <erikchen@chromium.org>
Date: Wed Jun 01 18:59:08 2016

Add more WebGL pixel tests.

Added tests for antialiasing, alpha channel, and Chromium image.

BUG= 607130 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[delete] https://crrev.com/9bc3781bd7dd8972a0b36c996e003871af23f433/content/test/data/gpu/pixel_webgl.html
[add] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/data/gpu/pixel_webgl_aa_alpha.html
[add] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/data/gpu/pixel_webgl_aa_noalpha.html
[add] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/data/gpu/pixel_webgl_noaa_alpha.html
[add] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/data/gpu/pixel_webgl_noaa_noalpha.html
[modify] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/data/gpu/pixel_webgl_util.js
[modify] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/gpu/gpu_tests/pixel_expectations.py
[modify] https://crrev.com/fc773b807b0d136aa17e2ac18a55bdd2810118bc/content/test/gpu/page_sets/pixel_tests.py

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

commit 24291cdf807dfea8d98a9aa17f09a50132b02360
Author: erikchen <erikchen@chromium.org>
Date: Thu Jun 02 08:28:18 2016

Enable new WebGL pixel tests.

All the reference images have been generated.

BUG= 607130 

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

[modify] https://crrev.com/24291cdf807dfea8d98a9aa17f09a50132b02360/content/test/gpu/gpu_tests/pixel_expectations.py

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

commit c34f049e6f49920680eb5634502b22511d7e03f9
Author: erikchen <erikchen@chromium.org>
Date: Thu Jun 02 19:44:26 2016

Use GL_RGBA renderbuffer for antialiased, no-alpha DrawingBuffers.

Intel GPUs suffer performance penalties with GL_RGB multisampled renderbuffers.
This CL turns on GL_RGB emulation for those GPUs.

BUG= 607130 

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

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

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

commit 7843491fb012d3d3a37f77355b92d999da732bca
Author: erikchen <erikchen@chromium.org>
Date: Fri Jun 10 18:17:43 2016

WebGL: Three small fixes to Image CHROMIUM logic.

1. Use the newly added method DescheduleUntilFinishedCHROMIUM() to add back
pressure.
2. Update the color mask appropriately before calling clearFramebuffers().
3. Plumb gpuMemoryBufferId through to the mailbox.

BUG= 611805 ,  617249 ,  607130 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

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

[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h

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

commit 7843491fb012d3d3a37f77355b92d999da732bca
Author: erikchen <erikchen@chromium.org>
Date: Fri Jun 10 18:17:43 2016

WebGL: Three small fixes to Image CHROMIUM logic.

1. Use the newly added method DescheduleUntilFinishedCHROMIUM() to add back
pressure.
2. Update the color mask appropriately before calling clearFramebuffers().
3. Plumb gpuMemoryBufferId through to the mailbox.

BUG= 611805 ,  617249 ,  607130 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel

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

[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/7843491fb012d3d3a37f77355b92d999da732bca/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h