New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 765729 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
OOO until 2019-01-24
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocked on:
issue 699566

Blocking:
issue 769488



Sign in to add a comment

Epic Zen Garden doesn't render (completely transparent)

Project Member Reported by kbr@chromium.org, Sep 15 2017

Issue description

Chrome Version: 63.0.3213.0 (Official Build) canary (64-bit)
OS: macOS (MacBook Pro with either NVIDIA or AMD GPU)

What steps will reproduce the problem?
(1) Visit the URL for the pre-release Epic Zen Garden build from Issue 764824.

What is the expected result?

Expect it to render.

What happens instead?

The canvas is completely transparent.

This is a current build of Epic's Zen Garden demo via the Emscripten toolchain which renders via WebGL 2.0. The previous build:
  https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html
renders correctly. There were rendering issues fixed in  Issue 699566  and follow-on bugs. It seems that the rendering techniques used by the demo have changed and a new bug is being triggered.

The bug is somewhere in the emulation of the RGB back buffer on top of an IOSurface. Running with the command line flag:
  --disable-features=WebGLImageChromium
which causes Chromium to use its old texture-backed WebGL framebuffer, makes the demo render.

However, with this command line flag, there is some significant jitter -- as though frames were occasionally being displayed out of order -- which seems new in this build. Running the older build with the above command line flag, the same jitter can be seen occasionally, though much less frequently.

(This bug is being filed separately from Issue 764824, and made public, so that the URL of the prerelease demo isn't released since we haven't received explicit permission to do so.)

 

Comment 1 by kbr@chromium.org, Sep 15 2017

Issue 764824 has been merged into this issue.

Comment 2 by kbr@chromium.org, Sep 15 2017

Used --enable-gpu-client-logging to grab a (huge) trace and tracked it down to failure to use ScopedRGBEmulationColorMask inside WebGL2RenderingContextBase::clearBufferfv, so the application's use of that entry point was blowing away the alpha channel. Patch and conformance test incoming.

Project Member

Comment 3 by bugdroid1@chromium.org, Sep 15 2017

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

commit af8c8baf31af880915d1b77be138be7c1e82c370
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Sep 15 20:45:20 2017

Use ScopedRGBEmulationColorMask inside clearBuffer.

The default back buffer's color attachment is currently RGB(A)8, and
it's legal to use clearBufferfv with it. The emulation done on macOS
of an RGB back buffer on top of an RGBA texture needs to be done in
this entry point. Do it for all of the clearBuffer entry points
(except clearBufferfi, which is only for use with depth/stencil) to
avoid problems later as support for different color spaces is added to
HTMLCanvasElement.

BUG= 765729 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: I4e7ee1ab1045c8cf606a7d93a2addcd3c0d961b4
Reviewed-on: https://chromium-review.googlesource.com/668238
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502356}
[modify] https://crrev.com/af8c8baf31af880915d1b77be138be7c1e82c370/third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp

Comment 4 by kbr@chromium.org, Sep 16 2017

Cc: lafo...@chromium.org bradnelson@chromium.org nattestad@chromium.org
Labels: Merge-Request-62
Status: Fixed (was: Started)
Fixed. Requesting merge to M-62. It turns out this isn't a regression, but affects a major partner's HTML5 / WebAssembly / WebGL content, and we would like to get the fix out as soon as possible. The fix is small, safe, well understood, and has a regression test (merging it into the Chromium repository now).

Comment 5 by kbr@chromium.org, Sep 16 2017

Labels: ReleaseBlock-Stable M-63
Project Member

Comment 6 by sheriffbot@chromium.org, Sep 16 2017

Labels: -Merge-Request-62 Merge-Review-62 Hotlist-Merge-Review
This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

Comment 7 by bugdroid1@chromium.org, Sep 17 2017

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

commit 37f0b5bfd017a546822e698587cab533cce7d007
Author: Kenneth Russell <kbr@chromium.org>
Date: Sun Sep 17 10:06:40 2017

Roll WebGL 559e304..365cb1e

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/559e304..365cb1e

BUG= 756293 ,  765729 ,  765953 ,  angleproject:2140 ,  angleproject:2141 ,  angleproject:2142 
TBR=zmo@chromium.org, kainino@chromium.org
TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: I0b68ded8bb565c9786269612038f3b903eb02041
Reviewed-on: https://chromium-review.googlesource.com/669724
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502524}
[modify] https://crrev.com/37f0b5bfd017a546822e698587cab533cce7d007/DEPS
[modify] https://crrev.com/37f0b5bfd017a546822e698587cab533cce7d007/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/37f0b5bfd017a546822e698587cab533cce7d007/content/test/gpu/gpu_tests/webgl_conformance_expectations.py
[modify] https://crrev.com/37f0b5bfd017a546822e698587cab533cce7d007/content/test/gpu/gpu_tests/webgl_conformance_revision.txt

Labels: -Merge-Review-62 Merge-Approved-62
Approving merge to M62. Branch: 3202

Comment 9 by kbr@chromium.org, Sep 20 2017

Cc: kbr@chromium.org
 Issue 766646  has been merged into this issue.
Project Member

Comment 10 by bugdroid1@chromium.org, Sep 20 2017

Labels: -merge-approved-62 merge-merged-3202
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8ee59f53559f59990fe628c6b759dacae251d369

commit 8ee59f53559f59990fe628c6b759dacae251d369
Author: Kenneth Russell <kbr@chromium.org>
Date: Wed Sep 20 01:41:12 2017

Use ScopedRGBEmulationColorMask inside clearBuffer.

The default back buffer's color attachment is currently RGB(A)8, and
it's legal to use clearBufferfv with it. The emulation done on macOS
of an RGB back buffer on top of an RGBA texture needs to be done in
this entry point. Do it for all of the clearBuffer entry points
(except clearBufferfi, which is only for use with depth/stencil) to
avoid problems later as support for different color spaces is added to
HTMLCanvasElement.

BUG= 765729 
TBR=kbr@chromium.org

(cherry picked from commit af8c8baf31af880915d1b77be138be7c1e82c370)

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;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
Change-Id: I4e7ee1ab1045c8cf606a7d93a2addcd3c0d961b4
Reviewed-on: https://chromium-review.googlesource.com/668238
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#502356}
Reviewed-on: https://chromium-review.googlesource.com/674385
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#342}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/8ee59f53559f59990fe628c6b759dacae251d369/third_party/WebKit/Source/modules/webgl/WebGL2RenderingContextBase.cpp

Labels: TE-NeedsTriageFromMTV
Tested this issue on MacBook Pro 10.13 (Radeon pro Intel HD graphics) using chrome latest beta #62.0.3202.38 by following steps mentioned in the original comment, observed the video rendered as expected. 

Tested the same on chrome #63.0.3213.0 and observed some errors and unable to play the video and it displays some download error. Not sure if it's gpu specific issue,currently HYD chrome-TE team doesn't have NVIDIA or AMD GPU machine to verify this issue. Requesting some one from MTV team to look in to it.

Thanks!
Labels: -TE-NeedsTriageFromMTV TE-Verified-62.0.3202.38
Verified this issue on Latest Beta#62.0.3202.38 and Canary#63.0.3225.0 for Mac OS X 10.13 (NVIDIA GeForce GT 650M) and the video (https://s3.amazonaws.com/unrealengine/HTML5/TestBuilds/Release-4.17.1-CL-3637171/Zen-HTML5-Shipping.html) renders w/o any issues.

PS: I could able to repro this rendering issue on previous beta#62.0.3202.29 w/ the same machine.

Thank you!

Comment 13 by kbr@chromium.org, Sep 27 2017

Blocking: 769488

Sign in to add a comment