On Mar 15, 2013, at 1:19 AM, Gregg Tavares <g...@google.com> wrote: > > I don't understand the opposition to "alpha" > > You set colors in Canvas2d with rgb or rgba. That 'a' in rgba stands for > alpha. > You can set a global alpha for drawing with context.globalAlpha > You read data from getImageData that returns red, green, blue, alpha > You write data to putImageData wit red, green, blue, alpha
I think made the case for why "alpha: false" is confusing and ambiguous. It does not disable any of the above features, so far as I know. > I also don't understand why if getContext("webgl", { alpha: false }) has been > shipping for 3 years there's a need to make it different on canvas 2d? Is there a nontrivial amount of content depending on it? That would be more relevant precedent than merely being in the code base. > Picking a different name or picking a different method (a function, an > attribute on canvas or context) seems like bikeshedding rather than some > functional objection. Besides naming, some of the suggested alternatives make a functional difference. Regards, Maciej P.S. One thing I'd like to know - if an opaque alpha/false canvas is itself composited (maybe CSS opacity is set on an ancestor), is it still somehow magically forced to ignore alpha, or does it composite as usual? If it's not forced opaque in the face of ancestor compositing, then I think that breaks the premise of using opaqueness as a trigger for subpixel anti-aliasing, which I thought was one of the main points of this. Note that opacity can change, so you can't just check CSS opacity of ancestors at the time of drawing into the canvas.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev