For me, this renders the same in Version 62.0.3202.94 (Official Build) (64-bit), vs Version 64.0.3273.0 (Official Build) canary (64-bit), vs Safari. OSX 10.12.6.

The only difference stated in the OP is the OSX version.

Please provide the contents of about:gpu from your system. This renders fine on Canary on 10.12.6 and is probably related to one of the graphics driver bugs that have been seen in 10.13.

Here you go, the output of about:gpu .

Thanks for investigating!

Deleted: gpu.html 61.3 KB

gpu.html 61.3 KB View Download

Screenshot of https://tobireif.com/demos/merry_christmas/ in Canary.

Deleted: screenshot_canary.png 73.4 KB

	screenshot_canary.png 73.4 KB View Download

Basic info from above gpu.html for convenience: Mac/Intel Iris Pro (I think it's Iris 5100?), macOS 10.13.1

Iris Pro 5200, I mean.

If there's anyone from Apple: I linked this issue report at https://bugreport.apple.com/web/?problemID=35648221 .

I can reproduce on a MacBook Air with Intel HD 5000. Chrome Stable works and Chrome Canary doesn't. I'll run a bisect. Checking out the sources to be able to do so.

Note: the sample runs correctly on a MacBook Air with Intel HD 6000. The bug's isolated to this particular GPU.

You are probably looking for a change made after 517633 (known good), but no later than 517673 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/65feca2a13cfb5f02f93169ae7f99cc36f7a17cc..e9374ae205116caa8c5bcea63b01ae53724b2961

Going to try a per-revision bisect; the blamelist is quite large.

You are probably looking for a change made after 517658 (known good), but no later than 517659 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/e2d08f68c73a9057d749fb32f21ef8f76fdf3c49..913195d22f782d61e86944b0ac0bfe45bf1df88e

The breakage was caused by my fix for  Issue 599285 . Will try to figure out what will fix it. Blocking fixing  Issue 786643  on this one.

Running r517633 with --disable-features=WebGLImageChromium displays a black screen. The non-IOSurface path's broken on this hardware for some reason (with this content, anyway).

Submitter: is there any way you can get Pixi.js to create its WebGL context without specifying the premultipliedAlpha context creation attribute (allowing it to default to true)? Or does its blending assume it's set to false? If you can get it to set it to true, that will work around this bug.

If you can help make a smaller reproducible test case for this that would help. The breakage is restricted only to the Intel HD 5000. The Intel HD 6000 works.

Hi KBR, thanks for investigating!

"is there any way you can get Pixi.js to create its WebGL context without specifying the premultipliedAlpha context creation attribute (allowing it to default to true)? Or does its blending assume it's set to false? If you can get it to set it to true, that will work around this bug."

A fix in Chrome would be much better than a workaround in PixiJS.

If you fix it in Chrome it will work for everyone, not just for PixiJS.

"The breakage was caused by my fix for  Issue 599285 ."

I hope you can fix both issues.

My demo works in current stable, so the issue seems fixable to me :)

Tobi

Please try both, make a fiddle with it.

```
new PIXI.WebGLRenderer(... , { transparent: 'notMultiplied'});
```

```
new PIXI.WebGLRenderer(... , { transparent: false});
```

(Everybody meet Ivan, he's a PixiJS developer.)

Hi Ivan, thanks for the comment!

A fix in Chrome would be much better than a workaround in PixiJS.

Also it seems feasible to fix the issue in Canary because the demo works in Chrome on the same machine.

Thus I'm hoping that the issue will get fixed in Chromium.

Tobi

@tobi please add two versions of this thing with those options, dont annoy devs.

"If you can help make a smaller reproducible test case for this that would help."

This basic PixiJS example works in Chrome but doesn't work in Canary:
http://pixijs.io/examples/#/basics/basic.js

I also attached a zip of my demo.

If the issue doesn't get fixed in Canary, most/many existing PixiJS/WebGL pages would be broken by the next Chrome (on that type of hardware, which includes many MacBook Pro machines). A workaround in my demo or in PixiJS would not prevent that, because there also might be non-PixJS WebGL pages that would be broken by Chrome.

You can't expect every existing PixiJS page to add a workaround or to update to a PixiJS version that contains a workaround. It most likely would not happen for every affected page. Some of the existing pages that use PixiJS are not maintained anymore, but are expected to continue to work in Chrome - just as they do in other browsers.

Just a few examples: These demos work in Chrome, but don't work in Canary:

http://lawriecape.co.uk/wiblr/

https://codepen.io/stefanweck/full/Vbgeax/

https://codepen.io/osublake/full/XXbLer/

Please ensure that Chrome will continue to render existing PixiJS pages, on this type of hardware and on all types of devices.

Deleted: merry_christmas_copy.zip 722 KB

merry_christmas_copy.zip 722 KB Download

The only affected hardware is the Intel HD 5000. I've tested with the Intel HD 6000 and your demo is working fine there.

I'll try to add the code path soon which will make premultipliedAlpha:false render in the same way as premultipliedAlpha:true, which will make this bug disappear, though it won't solve the underlying problem (which is still unknown, but is likely to be a bug in the graphics driver.)

The model "MacBook Pro (Retina, 15-inch, Mid 2015)" for example contains the Intel HD 5000, so I'd guess that there are thousands of machines containing that hardware component. Anyways:

"I'll try to add the code path soon which will [...] make this bug disappear"

Sounds good! When you implemented this, please let me know how I can check it out. I'd like to help by verifying that the demo gets rendered by future Chrome as well as it gets rendered by current Chrome (and by eg Firefox and Safari Tech Preview) and that there there won't be any new rendering issues. I can always get the latest Canary, or enable flags, or follow instructions eg for getting/compiling the latest dev.

https://chromium-review.googlesource.com/846478 is up for review and should fix this bug, though I don't have the hardware with me to confirm that. Will confirm later this week.

Note: will want to merge this fix back to M64 once landed and confirmed. It's small and self-contained and will prevent potentially a lot of pixi.js content from being broken on this particular GPU -- which we've seen quite a few Chrome Mac users still using in  Issue 794819 .

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

commit 3a29249f6ceb860047ea9274a6b639d41654d1b1
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Jan 04 01:18:43 2018

Manually handle WebGL's premultipliedAlpha:false with GpuMemoryBuffers.

Most OS compositors expect premultiplied alpha content. If the user
selects non-premultiplied rendering and WebGL is rendering into a
GpuMemoryBuffer, then make one last copy of the user's rendered
content into the GMB, premultiplying alpha at that point. This allows
the OS's compositor to handle premultipliedAlpha:false WebGL content
rather than falling back to Chrome's GL compositor.

BUG= 786945 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ib43828bf9b02fcad38d210096adfc00a61804766
Reviewed-on: https://chromium-review.googlesource.com/846478
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526885}
[modify] https://crrev.com/3a29249f6ceb860047ea9274a6b639d41654d1b1/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/3a29249f6ceb860047ea9274a6b639d41654d1b1/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h

Confirmed by comparing the two builds before and after the fix above:

https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/526871/
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/526894/

that the issue on the Intel HD 5000 is fixed. https://tobireif.com/demos/merry_christmas/ renders again on this device.

Requesting merge back to Chrome 64. We can let this bake in Canary for a few days, but the change seems low risk to me given that it's passed all tests.

 Issue 786643  has been merged into this issue.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Approving merge to M64. Branch:3282

Thank you all!

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

commit 4c4bfb3e731be5dac0f13336ebd4da7227e6a9dd
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Jan 06 00:50:23 2018

Manually handle WebGL's premultipliedAlpha:false with GpuMemoryBuffers.

Most OS compositors expect premultiplied alpha content. If the user
selects non-premultiplied rendering and WebGL is rendering into a
GpuMemoryBuffer, then make one last copy of the user's rendered
content into the GMB, premultiplying alpha at that point. This allows
the OS's compositor to handle premultipliedAlpha:false WebGL content
rather than falling back to Chrome's GL compositor.

BUG= 786945 
TBR=kbr@chromium.org

(cherry picked from commit 3a29249f6ceb860047ea9274a6b639d41654d1b1)

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ib43828bf9b02fcad38d210096adfc00a61804766
Reviewed-on: https://chromium-review.googlesource.com/846478
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#526885}
Reviewed-on: https://chromium-review.googlesource.com/853168
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#429}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/4c4bfb3e731be5dac0f13336ebd4da7227e6a9dd/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/4c4bfb3e731be5dac0f13336ebd4da7227e6a9dd/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h

This demo
https://tobireif.com/demos/merry_christmas/
now works in Canary again. It gets rendered, and I can't spot any flaws. Thanks!

Also: These three demos (for example) als get rendered in Canary again:
http://lawriecape.co.uk/wiblr/
https://codepen.io/stefanweck/full/Vbgeax/
http://pixijs.io/examples/#/basics/basic.js

Thanks tobi@. Please also help us by verifying Chrome Beta on your setup. Thanks.

Tested this issue on Mac-10.12.6 & 10.13.2 using chrome-64.0.3282.85 as per C#0 & C#32.

Below all URL's are rendered without any issue:
-----------------------------------------------
https://tobireif.com/demos/merry_christmas/
http://lawriecape.co.uk/wiblr/
https://codepen.io/stefanweck/full/Vbgeax/
http://pixijs.io/examples/#/basics/basic.js

Please find the attached screencast for reference.Hence adding TE-Verified labels.

Thanks..!

Deleted: 786945-Mac.webm 16.3 MB

786945-Mac.webm 16.3 MB Download

Hi Ken! I downloaded the .dmg from
https://www.google.com/chrome/browser/beta.html
-> button "Download Chrome Beta".

The file is named "GoogleChrome.dmg". (strangely no "Beta" in the file name)

When I run that newly installed "Google Chrome.app", the version is the same as stable.

Sorry, I thus currently can't test in Chrome Beta.

Any tips?

(But everything works in Canary, on my setup, as reported in Comment 32.
I just now checked the Christmas demo in Canary again, and it still works.)

On macOS you will temporarily need to quit and uninstall Chrome Stable in order to properly install Chrome Beta. about:version will confirm that you're running beta instead of stable.

Bad news: the demo
https://tobireif.com/demos/merry_christmas/
is blank/black in Chrome Beta "Version 64.0.3282.71 (Official Build) beta (64-bit)" on my MacBook.

It works in Canary ("Version 65.0.3317.0 (Official Build) canary (64-bit)
").

I also still works in Chrome stable ("Version 63.0.3239.132 (Official Build) (64-bit)
").

MacOS on my machine has changed to 10.13.2 (17C205) since the initial report.
Still the same hardware: "Intel Iris Pro 1536 MB".

Thanks for testing. I see from https://omahaproxy.appspot.com/ that Chrome Beta hasn't rolled forward to pick up the merge-back of this fix yet. Appreciate your help testing the next Beta build.

I installed the latest Chrome Beta:
"Version 64.0.3282.85 (Official Build) beta (64-bit)"

My demo
https://tobireif.com/demos/merry_christmas/
works, flawlessly.

These also work:
http://pixijs.io/examples/#/basics/basic.js
http://lawriecape.co.uk/wiblr/
https://codepen.io/stefanweck/full/Vbgeax/
https://codepen.io/osublake/full/XXbLer/

Thanks!

Thanks tobi@ for re-testing.