- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 14 Feb 2013 15:16:56 +1100
- To: robert@ocallahan.org
- Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>, Stephen White <senorblanco@chromium.org>
On Thu, Feb 14, 2013 at 2:27 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan <robert@ocallahan.org>wrote: >> >>> On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier <cabanier@gmail.com>wrote: >>> >>>> What would happen if you set 'opaque' to true and you draw with alpha >>>> and >>>> 'copy' compositing? It seems that that has the same issue (unless >>>> you're OK >>>> with breaking drawing). >>>> >>> >>> The alpha values of all moz-opaque canvas pixels are simply not affected >>> by compositing. >>> >> >> Exactly! So, this will break drawing as the pixels with no alpha will be >> black with no way to undo that. >> > > I don't know what you mean by "no way to undo that" or "break drawing". > > My proposal doesn't change anything for the user as it has no side effects (apart from faster drawing when possible). Setting 'opaque' on the canvas actually changes how compositing works. For instance, if you use 'copy' compositing with a partially transparent image, you will draw black pixels where the image has no coverage. In addition, partially transparent pixels will look darker the more transparent they are. 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?
Received on Thursday, 14 February 2013 04:17:21 UTC