This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://wiki.whatwg.org/wiki/CanvasOpaque On Tue, 23 Jul 2013, Stephen White wrote: > On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson <ian@hixie.ch> wrote: > > > > This thread was gigantic and involved many proposals. I've only included > > the last one below, since it seemed to take into account the most of the > > feedback mentioned on the thread; I haven't responded to all the > > intermediate e-mails which were mainly just a discussion amongst > > contributors, and not direct feedback on the spec itself. > > > > I haven't yet changed the spec. The main thrust of the feedback below ends > > with the proposal to use WebGL's 'alpha' feature for the 2D context; is > > this what implementors want to do? > > We're implementing this in Chromium (currently behind the "experimental > canvas features" flag).
moz-opaque: https://bugzilla.mozilla.org/show_bug.cgi?id=430906 Blink intent-to-ship thread: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/4KMwyiaOxHg/0OOogCofycYJ implementation: https://code.google.com/p/chromium/issues/detail?id=234297
Update: the WebGL-style 'alpha' feature is now fully exposed in the Blink/Chromium trunk, and on course to ship in Chrome 32.
https://groups.google.com/forum/#!topic/mozilla.dev.platform/5i8H-xKGtEg
Ok, my plan is to reverse engineer Chrome and Firefox implementations of what is described here: http://wiki.whatwg.org/wiki/CanvasOpaque I'll then try to spec the interoperable subset.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3006 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3007 One difference between Chrome and Firefox is that Chrome blanks the canvas when you call getContent(), whereas Firefox waits until the first time you draw to the canvas, or call getImageData(): http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3008 Another is that Chrome treats 'alpha:undefined' like 'alpha:false': http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3009
(In reply to Ian 'Hixie' Hickson from comment #5) > One difference between Chrome and Firefox is that Chrome blanks the canvas > when you call getContent(), whereas Firefox waits until the first time you > draw to the canvas, or call getImageData(): Chrome used to behave as you describe for Firefox, but we considered it to be a bug. Firefox should probably make the same fix we made. FWIW: Chrome, just like Firefox, defers the allocation of the canvas backing store until something is actually drawn, and if the canvas needs to be painted before then, and it has alpha:false, the then we just draw an opaque black rect (backing store creation continues to be deferred). See: http://src.chromium.org/viewvc/blink?view=revision&revision=171408 > Another is that Chrome treats 'alpha:undefined' like 'alpha:false' Isn't that the right thing to do? ECMAScript spec says conversion of undefined to bool gives false.
roc, any opinion on the effect of getContext(... alpha:false) before script does any painting? I tend to agree with Justin that it should immediately make the element opaque, especially given that getImageData() returns opaque data (and causes the canvas to change colour!). > > Another is that Chrome treats 'alpha:undefined' like 'alpha:false' > > Isn't that the right thing to do? ECMAScript spec says conversion of > undefined to bool gives false. It depends. If it's a dictionary, then it's wrong, because 'undefined' is treated as absent and triggers the default value (presumably, in this case, true) according to WebIDL.
(In reply to Ian 'Hixie' Hickson from comment #7) > It depends. If it's a dictionary, then it's wrong, because 'undefined' is > treated as absent and triggers the default value (presumably, in this case, > true) according to WebIDL. Oh, thanks. I will fix it.
So, assuming roc is ok with the Chrome behaviour described above, I guess the way this would work is that the 2D context creation algorithm would see if there was a first argument, and if there was, convert it to a dictionary of a type that had one member 'alpha' of type 'boolean' defaulting to 'true', and then check if that dictionary had an 'alpha' member with value false, and if so, flag the context as being opaque. Then... yikes, what exactly do I have to change? Is it sufficient to put a single requirement somewhere that says to clamp the opacity when painting, plus driving the fourth byte to 255 in getImageData() and ignoring every fourth byte in putImageData()? Or is it more subtle than that? Is it just equivalent to the canvas having a forced black bacground?
I agree that the Chrome behavior is correct and the Firefox behavior is a bug.
So what is it that this actually requires at the canvas level? (See paragraph 2 of comment 9 above.)
(In reply to Ian 'Hixie' Hickson from comment #9) > Then... yikes, what exactly do I have to change? Is it sufficient to put a > single requirement somewhere that says to clamp the opacity when painting, > plus driving the fourth byte to 255 in getImageData() and ignoring every > fourth byte in putImageData()? That sounds right to me. There might be some extra things that need to be patched but I can't think of any right now. BTW this is an example of a situation where stating some redundant invariants in the spec would be helpful. If the spec says (normatively) that the alpha value of every pixel in an opaque canvas is 255 (or 1.0), then if someone discovers another part of the spec which implies an alpha value in an opaque canvas can be something else, we know it's a bug in the spec, and not just some very subtle intended behavior.
Thanks. (In reply to Robert O'Callahan (Mozilla) from comment #12) > BTW this is an example of a situation where stating some redundant > invariants in the spec would be helpful. If the spec says (normatively) that > the alpha value of every pixel in an opaque canvas is 255 (or 1.0), then if > someone discovers another part of the spec which implies an alpha value in > an opaque canvas can be something else, we know it's a bug in the spec, and > not just some very subtle intended behavior. You'd think, but in practice (a) it turns out the invariants are wrong as often as the prose contradicting them, and (b) when there _is_ a conflict, implementors tend to try really hard to find ways to interpret the spec so that there's no conflict, even if it means interpreting both parts in wildly crazy ways. But yeah. There's some asserts here or there (sometimes in <!--comments-->, sometimes in non-normative notes, sometimes just in the way that things are phrased, especially in the case of "otherwise" clauses, e.g. "if A, then X, otherwise not-A, Y").
Let me know if this is a bad way to spec it. Thanks.
Checked in as WHATWG revision r8755. Check-in comment: Define getContext('2d', {alpha:false}). http://html5.org/tools/web-apps-tracker?from=8754&to=8755