dalecurtis@ plz triage

Seems like it's working fine on Linux 72.0.3626.28 -- don't have a Mac today but can try on Wednesday. Can you try going to chrome://flags and disabling accelerated canvas?

Also try running with --disable-gpu-memory-buffer-video-frames

disabling accelerated canvas doesn't help but adding the --disable-gpu-memory-buffer-video-frames argument does. Doing that also fixes https://bugs.chromium.org/p/chromium/issues/detail?id=905249

Seems something specific to Mac, enabling GPU memory buffers on Linux doesn't show the same issue. I wonder if alpha resources aren't being created correctly. Will test on Wednesday when I have my mac if ccameron doesn't beat me to it.

The NextAction date has arrived: 2019-01-09

Yeah specific to Mac.

https://chromium-review.googlesource.com/c/chromium/src/+/1404579 fixes this, but not sure it's correct / won't break other platforms. Will test.

Mac fix breaks Linux. For some reason the Mac GpuMemoryBuffer's are expecting the alpha channel _without_ pre-attenuatation/pre-multiply while Linux wants the opposite. +dcastagna

dcastagna/ccameron: Any idea why Mac and Linux might be functioning differently in regard to their alpha channels? Is it because we're directly using an IOSurface backed GMB on Mac that may not go through our compositor?

We usually use premul in the compositor, https://chromium-review.googlesource.com/c/chromium/src/+/1404579 will likely break other platforms. Scanning out from a buffer with non premul doesn't work, we noticed that when a webgl canvas outputs non premultiplied colors.

Dale, can you try forcing GL composition on Mac and verify if we have the same issue?

--disable-gpu fixes the issue as well. I think GL composition is enabled by default, so not sure what you wanted me to test otherwise.

What I meant by forcing GL composition is to avoid deferring compositing of IOSurface to Core Animation and always use GLRenderer to flatten quads.

const char kDisableMacOverlays[] = "disable-mac-overlays";
is the flag I'd try.

If with that flag we observe the same issue, at least we know that GL Compositing and IOSurface overlay display path behave the same way.

Okay, will try when I have my mac next.

FTR I just compiled Chromium ToT on my MBP 10.14.2, and run
with and without the command-line flag --disable-mac-overlays,
the site https://simpl.info/videoalpha/, which has two VP8
videos with transparency, and in both cases the reproduction
was visually correct: the transparent background of the two
floating videos was fully transparent etc.

The video [1] is indeed recognised as VP9 with transparency,
in all cases decoded by VpxVideoDecoder, all producing 
PIXEL_FORMAT_I420A.

More importantly, I cannot repro the bug description, i.e.
using my Chromium ToT build and the codepen, I'm always 
seeing the box as grey in the original video, both when
inline and when not. 

ToT is r623723 for me now.

[1] https://launchinteractive.com.au/chrome/whiteSquare.webm

Definitely still pink on Linux ToT, so something Mac specific must be happening.

The NextAction date has arrived: 2019-01-18

--disable-gmb still fixes the issue. --disable-mac-overlays doesn't help.

I can confirm that I always see grey now on ToT even without capturing. @mcasas are you on Mojave? I just upgraded on Wednesday, otherwise maybe something changed in ToT.

@dcastagna, ccameron: Any further tips?