23515 2013-10-14 22:11:07 +0000 <canvas>: opaque backing stores 2014-09-08 22:53:21 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 enhancement Unsorted 1 ian ian ed ian junov mike roc senorblanco contributor oldest_to_newest 94724 0 ian 2013-10-14 22:11:07 +0000 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). 94760 1 ed 2013-10-15 13:07:50 +0000 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 94771 2 junov 2013-10-15 15:04:23 +0000 Update: the WebGL-style 'alpha' feature is now fully exposed in the Blink/Chromium trunk, and on course to ship in Chrome 32. 102247 3 ian 2014-03-12 18:07:35 +0000 https://groups.google.com/forum/#!topic/mozilla.dev.platform/5i8H-xKGtEg 102830 4 ian 2014-03-24 16:10:10 +0000 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. 105244 5 ian 2014-05-06 21:43:23 +0000 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 105253 6 junov 2014-05-06 22:40:59 +0000 (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. 105326 7 ian 2014-05-07 18:15:30 +0000 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. 105342 8 junov 2014-05-07 20:38:25 +0000 (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. 105353 9 ian 2014-05-07 21:32:30 +0000 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? 105356 10 roc 2014-05-07 21:45:30 +0000 I agree that the Chrome behavior is correct and the Firefox behavior is a bug. 109706 11 ian 2014-07-31 20:56:32 +0000 So what is it that this actually requires at the canvas level? (See paragraph 2 of comment 9 above.) 109716 12 roc 2014-07-31 22:34:25 +0000 (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. 109718 13 ian 2014-07-31 22:45:20 +0000 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"). 111206 14 ian 2014-09-08 22:51:31 +0000 Let me know if this is a bad way to spec it. Thanks. 111207 15 contributor 2014-09-08 22:53:21 +0000 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