ok

Sorry for the noise. It sounds like the folks hadn't tested on Chrome Canary (55), and that it's working for them. I suspect this is a bug you fixed a while ago.

Unfortunately per https://github.com/mrdoob/three.js/issues/9685#issuecomment-248776127 it looks like this was still broken in M54. I think the associated pixel tests and final fixes only went into M55.

Can we disable the use of WebGLImageChromium by default in the M54 branch? Erik, what do you think about this?

I wasn't aware of any ChromiumImage related WebGL fixes that aren't in M54. 

Darn. Can you think of why this would be working in M55?

I wish we could reproduce this in house. I've tried on my available machines but it doesn't reproduce.

The CA compositor [and WebGL's interaction] hasn't changed much since M54.

Maybe a non-deterministic bug associated with the GPU? I guess we turned on CoreProfile in M55?

That might be the essential difference. Let's see what the response to https://github.com/mrdoob/three.js/issues/9685#issuecomment-248781433 is.

https://github.com/mrdoob/three.js/issues/9685#issuecomment-248793695 indicates that --disable-features=WebGLImageChromium does work around the problem on the AMD Radeon HD 6750M in Chrome 54.

What should we do? Adding a new blacklist entry in the M54 tree is not a good option due to the amount of new code that would have to be added.

This particular problem seems to be resolved in M55, but  Issue 649053 , reported against the same machines, seems to not be.

 Issue 649053  has been merged into this issue.

Per https://bugs.chromium.org/p/chromium/issues/detail?id=649053#c15 it is clear there is a problem with this code path on older AMD GPUs. What is needed:

1) Add a GPU driver bug workaround type for disabling the new code path; https://codereview.chromium.org/2354423002/ is a recent, simple and small example

2) Use the GPU blacklist to disable the new code path on GPUs of vendor ID 0x1002 and device IDs 0x6720 and 0x6741 on macOS

3) Make sure the GPU pixel tests on the bots cover both code paths

4) Turn off the experiment on Dev/Canary

Erik, can you take these tasks? Let me know if you're swamped. This is pretty high priority since WebGL is broken for users of old iMacs.

We should also really turn off the new code path completely on M54.

WebGL Image Chromium has been enabled by default since M53, which first started rolling out around 8/31:
https://googlechromereleases.blogspot.com/2016/08/stable-channel-update-for-desktop_31.html
"""
 [Reland 1] Reenable WebGL Image Chromium.
    
    The feature was disabled because of two bugs. Both have since been fixed.
    
    BUG= 617249 ,  581777 
    TBR=piman@chromium.org, kbr@chromium.org
    
    Review-Url: https://codereview.chromium.org/2085573002
    Cr-Commit-Position: refs/heads/master@{#400709}
"""

> We should also really turn off the new code path completely on M54.
I'm happy to start blacklisting WebGL Image Chromium on particular devices, but turning off the feature entirely any time we find a GPU on which it doesn't work seems like overkill. I bet that devices between, and around [0x6720, 0x6741] probably don't work either. 

(1), (2) Okay, can do.
(3) We already have those: see tests with "shared_page_state_class=WebGLNonChromiumImageSharedPageState". 
(4) Okay, can do.

fwiw, this issue is strongly reminiscent of an issue we've seen on old AMD GPUS:
https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list_json.cc?q=disable_webgl_rgb_multisampling_usage&sq=package:chromium&dr=C&l=1682

The workaround only applies to the device 0x68b8. I bet that extending it to the devices you mentioned will also fix the problem.

I tested this out on my old AMD gpu. When I turn off the workaround, I get the same bug. So this is fixable simply by expanding the workaround to include those devices.

Awesome. Thank you for realizing that it was that problem.

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

commit e9a527e058e65fcbfc37b817a5ef7e6693fbb209
Author: erikchen <erikchen@chromium.org>
Date: Fri Sep 23 22:46:29 2016

Expand the list of devices that require a GPU workaround.

Old AMD devices are known to require a workaround for colormasks on multisample
renderbuffers. This CL expands the list of devices known to need this
workaround.

BUG= 648466 
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/2363833002
Cr-Commit-Position: refs/heads/master@{#420756}

[modify] https://crrev.com/e9a527e058e65fcbfc37b817a5ef7e6693fbb209/gpu/config/gpu_driver_bug_list_json.cc

I have a question. 

If I set the canvas alpha:false - 
   Then I still want the render target to be BGRA(X), but the presentation mode of the canvas should ignore A(X) channel and show it opaque.

Why do I need ColorMask here ?
 

Your change meets the bar and is auto-approved for M54 (branch: 2840)

 Issue 649192  has been merged into this issue.

pkirill: The internal representation uses an RGBA IOSurface-backed texture, which needs the A-channel cleared to 1.

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

commit 0c26055fb6018dc18d1b4c5b27273dbb52a6c75b
Author: erikchen <erikchen@chromium.org>
Date: Mon Sep 26 16:57:01 2016

[Merge to 2840] Expand the list of devices that require a GPU workaround.

> Old AMD devices are known to require a workaround for colormasks on multisample
> renderbuffers. This CL expands the list of devices known to need this
> workaround.
>
> BUG= 648466 
> 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/2363833002
> Cr-Commit-Position: refs/heads/master@{#420756}
> (cherry picked from commit e9a527e058e65fcbfc37b817a5ef7e6693fbb209)

Review URL: https://codereview.chromium.org/2375443002 .

Cr-Commit-Position: refs/branch-heads/2840@{#530}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0c26055fb6018dc18d1b4c5b27273dbb52a6c75b/gpu/config/gpu_driver_bug_list_json.cc

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

commit 0c26055fb6018dc18d1b4c5b27273dbb52a6c75b
Author: erikchen <erikchen@chromium.org>
Date: Mon Sep 26 16:57:01 2016

[Merge to 2840] Expand the list of devices that require a GPU workaround.

> Old AMD devices are known to require a workaround for colormasks on multisample
> renderbuffers. This CL expands the list of devices known to need this
> workaround.
>
> BUG= 648466 
> 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/2363833002
> Cr-Commit-Position: refs/heads/master@{#420756}
> (cherry picked from commit e9a527e058e65fcbfc37b817a5ef7e6693fbb209)

Review URL: https://codereview.chromium.org/2375443002 .

Cr-Commit-Position: refs/branch-heads/2840@{#530}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0c26055fb6018dc18d1b4c5b27273dbb52a6c75b/gpu/config/gpu_driver_bug_list_json.cc

 Issue 695051  has been merged into this issue.