On Thu, Feb 14, 2013 at 3:35 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> Looking at the WebKit implementation, I'm unsure how 'opaque' can >> implemented for accelerated canvas. It might work with non-accelerated >> canvas but would have to run some experiments. >> I also look at mozilla's Core Graphics implementation and unless I'm >> missing something, it doesn't have special code to handle 'opaque'. When do >> you use this parameter? >> > > CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That > selects a surface format that is passed down to the graphics layer when > creating the canvas surface. It's true that we don't currently do anything > with that when drawing with CoreGraphics. That would need to be cleaned up > before we started promoting this feature. > > Now that you mention it, having to modify the definition of compositing is > a bit of a bummer for the 'opaque' attribute approach. I think we could do > everything we want using your approach --- internally keeping a flag to > indicate whether the alpha values of the canvas are all 1, setting it when > the canvas is filled with a solid color and clearing it when non-over > drawing (or clear()) are used. Let's try that! > > But I think "matte" is unnecessarily obscure. How about adding a > clear(DOMString) method that does a 'copy' of the color to the entire > canvas buffer? The color could default to rgba(0,0,0,0). Yes, that would work. Drawbacks are: - you can't draw onto a transparent backdrop and apply matting. - if you use a compositing mode that changes the canvas alpha to something else than 1, you can't optimize the drawing any more. Both these are caused because 'clear' removes the canvas content.