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

Issue 673416 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
█ reed@chromium.org
█ bsalomon@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

2D canvas with {alpha: false} does not strictly force alpha to be 255

Project Member Reported by junov@chromium.org, Dec 12 2016 
The current implementation of the alpha:false context creation parameter forces canvas contents to be composited as if it were fully opaque, but it does not actually force the alpha values of the image buffer to be 255 all the time.

Forcing the alpha values to 255 is what is mandated by the spec. Failure to do so has several side-effects. As illustrated by the following test case, the non-255 values are observable via getImageData:
https://jsfiddle.net/kpkov098/

Also, setting the context's global compositeOperation to an op that depends on the destinationAlpha will result in artifacts.

Comment 1 by nathan.f...@oculus.com, Apr 13 2017 

We hit an issue in Oculus Browser that I think is related to this (or exactly this) issue.

Ultimately the reduced repro I came up with is the same as yours, but additionally the Canvas needs to be large enough to trigger Accelerated rendering.

At that point, not only are the pixel values allowed to have alpha channel, but the alpha channel gets written into the final compositor output without blending (as expected, it is marked as opaque so uses Src transfer).  This means it can "punch a hole" in the compositor, even through cc::Layers behind the content layer.

I suppose this is happening in Chrome for Android but punching a hole yields a black background anyway (from the SurfaceView?  or from the Activity/contentView Android color?).  In Oculus Browser the Surface attached to the main compositor is transferred to the VR compositor with RGBA so you see a panel with a hole in it!

For example this sample shows the issue:  https://threejs.org/examples/raytracing_sandbox.html

We will certainly work around it in Oculus Browser going forward but I think if this issue were addressed then the combination of opaque (Src transfer) and having alpha channel would never be allowed, so no holes could get punched.

Comment 2 by acmesqua...@gmail.com, Aug 22 2017 

putImageData() over-writes alpha values.

Comment 3 by junov@chromium.org, Aug 29 2017

Cc: reed@chromium.org bsalomon@chromium.org
Components: Internals>Skia
To implement an efficient solution for this, we'd need skia's support.

We'd need to be able to set up an SkSurface with an RGB buffer, or an option that disable writing to the alpha channel.  For the GPU-accelerated path, this could be as simple as calling glColorMask

Comment 4 by fs...@chromium.org, Jun 29 2018

Cc: junov@chromium.org
Owner: ----
Status: Available (was: Assigned)

Comment 5 by junov@chromium.org, Jul 25

Cc: -junov@chromium.org
►

Sign in to add a comment