Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, Jan 10, 2012 at 12:52 PM, Ian Hickson wrote: > Should we still make shadows only work in source-over mode, or should we > leave the spec as is in this area? > It's probably not worth changing the spec at this time. I think it would be a bit simpler, and if we run into problems with shadows and non-over operators (author confusion, implementation issues) then I think we could still do it. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, 5 Jul 2011, Robert O'Callahan wrote: > On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan > wrote: > > On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote: > > > >> On Fri, 13 May 2011, Robert O'Callahan wrote: > >> > > >> > Can you put a note in the spec that we're thinking of changing this > >> > behavior, so developers are less likely to start depending on it, > >> > and we've got some cover in case it breaks some esoteric stuff that > >> > doesn't matter for compat? > >> > >> Done. > >> > > > > Thanks. I made this change on mozilla-central so it should appear in > > Firefox 7 about 18 weeks from now --- unless we detect that it breaks > > the Web. > > It breaks the Web, so we're backing it out. > > It turns out that a lot of canvas apps set up a shadow color and blur, > do some drawing, then disable the shadow by setting the blur to zero. > With the proposed change, those apps often render incorrectly, and > worse, they often render more slowly. Should we still make shadows only work in source-over mode, or should we leave the spec as is in this area? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan wrote: > On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote: > >> On Fri, 13 May 2011, Robert O'Callahan wrote: >> > >> > Can you put a note in the spec that we're thinking of changing this >> > behavior, so developers are less likely to start depending on it, and >> > we've got some cover in case it breaks some esoteric stuff that doesn't >> > matter for compat? >> >> Done. >> > > Thanks. I made this change on mozilla-central so it should appear in > Firefox 7 about 18 weeks from now --- unless we detect that it breaks the > Web. It breaks the Web, so we're backing it out. It turns out that a lot of canvas apps set up a shadow color and blur, do some drawing, then disable the shadow by setting the blur to zero. With the proposed change, those apps often render incorrectly, and worse, they often render more slowly. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote: > On Fri, 13 May 2011, Robert O'Callahan wrote: > > > > Can you put a note in the spec that we're thinking of changing this > > behavior, so developers are less likely to start depending on it, and > > we've got some cover in case it breaks some esoteric stuff that doesn't > > matter for compat? > > Done. > Thanks. I made this change on mozilla-central so it should appear in Firefox 7 about 18 weeks from now --- unless we detect that it breaks the Web. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Fri, 13 May 2011, Robert O'Callahan wrote: > > Can you put a note in the spec that we're thinking of changing this > behavior, so developers are less likely to start depending on it, and > we've got some cover in case it breaks some esoteric stuff that doesn't > matter for compat? Done. On Thu, 12 May 2011, Jonas Sicking wrote: > > (For what it's worth, I really wish we would do this for W3C bug 11960) Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Thu, May 12, 2011 at 9:32 PM, Robert O'Callahan wrote: > On Fri, May 13, 2011 at 3:19 PM, Ian Hickson wrote: > >> On Wed, 4 May 2011, Robert O'Callahan wrote: >> > 4) remove the no-shadow special case, but add a special case to not draw >> > shadows for operators other than source-over >> > >> > I think I prefer #4. I have yet to hear of any use-case that needs >> > shadows with an operator other than source-over, and it would probably >> > simplify the spec and implementations a little bit. >> >> #4 seems fine to me. Does anyone object to #4? I propose waiting until >> browser vendors implement this (to test that it is not a compatibility >> problem), and then updating the spec accordingly. >> > > Can you put a note in the spec that we're thinking of changing this > behavior, so developers are less likely to start depending on it, and we've > got some cover in case it breaks some esoteric stuff that doesn't matter for > compat? Yes! This is in general something we need to do more of. Migrating to better APIs is made much harder by having the spec say something different. (For what it's worth, I really wish we would do this for W3C bug 11960) / Jonas
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Fri, May 13, 2011 at 3:19 PM, Ian Hickson wrote: > On Wed, 4 May 2011, Robert O'Callahan wrote: > > 4) remove the no-shadow special case, but add a special case to not draw > > shadows for operators other than source-over > > > > I think I prefer #4. I have yet to hear of any use-case that needs > > shadows with an operator other than source-over, and it would probably > > simplify the spec and implementations a little bit. > > #4 seems fine to me. Does anyone object to #4? I propose waiting until > browser vendors implement this (to test that it is not a compatibility > problem), and then updating the spec accordingly. > Can you put a note in the spec that we're thinking of changing this behavior, so developers are less likely to start depending on it, and we've got some cover in case it breaks some esoteric stuff that doesn't matter for compat? Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Tue, 3 May 2011, Matthew Delaney wrote: > > The paragraph in the canvas spec that reads... > > "Shadows are only drawn if the opacity component of the alpha component > of the color of shadowColor is non-zero and either the shadowBlur is > non-zero, or the shadowOffsetX is non-zero, or the shadowOffsetY is > non-zero." > > ...I've found must have been modeled after a bug originally from > CoreGraphics. As you can see in this simple animation of a shadow blur > being reduced from 20 down to 0, this "edge case" outlined in the above > paragraph produces undesirable behavior at the end of the animation: > http://webstuff.nfshost.com/shadowblur.html > > This outlined edge case really only affects a particular case of when > the composite operation is set to destination-atop, which should result > in the shadow landing "on top of" its source, and both the offsets and > blur are of course 0. In the animation sample linked above, this case is > the end state of the animation (the rect turning all blue all of a > sudden). > > Since: > > 1) This behavior is obviously not ideal (see the linked animation above) > and is really just a bug > > 2) I can't imagine this particular edge case popping up all that often > (think: using destination-atop and having both the shadow offsets and > the blur 0 so that the shadow would otherwise be totally eclipsed by the > source?) > > 3) The only major browsers I've found to support this edge case are > Firefox4 (but not versions less than 4) and CG/Skia ports of WebKit > browsers (because this is where the bug originated) > > ...I'm proposing this: > > 1) Strip out this edge case paragraph in the spec (yay, cleaner spec!) > > 2) Notify Firefox team that they should strip out this hack in their > code for the edge case. > > 3) Quickly fix WebKit ports > > 4) File a bug against CG on this faulty behavior (just did that) and > hope that it can be fixed in future releases. > > 5) Ask philip/W3C nicely to update his/the test at > http://philip.html5.org/tests/canvas/suite/tests/2d.shadow.enable.off.2.html > http://w3c-test.org/html/tests/approved/canvas/2d.shadow.enable.off.2.html > > I also posted more info here: > https://bugs.webkit.org/show_bug.cgi?id=60091 > > I realize this is somewhat nit-picky, but it's clearly a bug (unless I'm > missing something obvious) that I think we can all quickly rectify. > Additionally, I've found a handful of other similar things in the canvas > spec that I will write about shortly, but wanted to test the waters of > emailing this list first to see how hard it is to push this "easier" > issue. ;-) On Wed, 4 May 2011, Robert O'Callahan wrote: > > See the thread " shadow compositing oddities" from July 2008. In > that thread, Eric Butler points out that always drawing shadows has > problems with operators other than dest-atop. For example, with > source-in, always drawing a fully transparent shadow would mean that > source-in acts just like clear! > > So as well as being compatible with CG, this behavior was thought to be > desirable because it provides a simple way for shadows to be completely > disabled by default, without requiring authors having to explicitly > enable shadows. > > So here are some options: > > 1) leave the spec as-is > > 2) introduce explicit API to enable/disable shadows (would break a lot > of Web content at this point, probably not realistic) > > 3) remove the no-shadow special case, as you suggest (breaks some > operators, probably not a good idea) > > 4) remove the no-shadow special case, but add a special case to not draw > shadows for operators other than source-over > > I think I prefer #4. I have yet to hear of any use-case that needs > shadows with an operator other than source-over, and it would probably > simplify the spec and implementations a little bit. #4 seems fine to me. Does anyone object to #4? I propose waiting until browser vendors implement this (to test that it is not a compatibility problem), and then updating the spec accordingly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal to remove a paragraph from canvas spec
On Wed, May 4, 2011 at 2:08 PM, Matthew Delaney wrote: > Since: > 1) This behavior is obviously not ideal (see the linked animation above) > and is really just a bug > See the thread " shadow compositing oddities" from July 2008. In that thread, Eric Butler points out that always drawing shadows has problems with operators other than dest-atop. For example, with source-in, always drawing a fully transparent shadow would mean that source-in acts just like clear! So as well as being compatible with CG, this behavior was thought to be desirable because it provides a simple way for shadows to be completely disabled by default, without requiring authors having to explicitly enable shadows. So here are some options: 1) leave the spec as-is 2) introduce explicit API to enable/disable shadows (would break a lot of Web content at this point, probably not realistic) 3) remove the no-shadow special case, as you suggest (breaks some operators, probably not a good idea) 4) remove the no-shadow special case, but add a special case to not draw shadows for operators other than source-over I think I prefer #4. I have yet to hear of any use-case that needs shadows with an operator other than source-over, and it would probably simplify the spec and implementations a little bit. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
[whatwg] Proposal to remove a paragraph from canvas spec
The paragraph in the canvas spec that reads... "Shadows are only drawn if the opacity component of the alpha component of the color of shadowColor is non-zero and either the shadowBlur is non-zero, or the shadowOffsetX is non-zero, or the shadowOffsetY is non-zero." …I've found must have been modeled after a bug originally from CoreGraphics. As you can see in this simple animation of a shadow blur being reduced from 20 down to 0, this "edge case" outlined in the above paragraph produces undesirable behavior at the end of the animation: http://webstuff.nfshost.com/shadowblur.html This outlined edge case really only affects a particular case of when the composite operation is set to destination-atop, which should result in the shadow landing "on top of" its source, and both the offsets and blur are of course 0. In the animation sample linked above, this case is the end state of the animation (the rect turning all blue all of a sudden). Since: 1) This behavior is obviously not ideal (see the linked animation above) and is really just a bug 2) I can't imagine this particular edge case popping up all that often (think: using destination-atop and having both the shadow offsets and the blur 0 so that the shadow would otherwise be totally eclipsed by the source?) 3) The only major browsers I've found to support this edge case are Firefox4 (but not versions less than 4) and CG/Skia ports of WebKit browsers (because this is where the bug originated) ...I'm proposing this: 1) Strip out this edge case paragraph in the spec (yay, cleaner spec!) 2) Notify Firefox team that they should strip out this hack in their code for the edge case. 3) Quickly fix WebKit ports 4) File a bug against CG on this faulty behavior (just did that) and hope that it can be fixed in future releases. 5) Ask philip/W3C nicely to update his/the test at http://philip.html5.org/tests/canvas/suite/tests/2d.shadow.enable.off.2.html / http://w3c-test.org/html/tests/approved/canvas/2d.shadow.enable.off.2.html I also posted more info here: https://bugs.webkit.org/show_bug.cgi?id=60091 I realize this is somewhat nit-picky, but it's clearly a bug (unless I'm missing something obvious) that I think we can all quickly rectify. Additionally, I've found a handful of other similar things in the canvas spec that I will write about shortly, but wanted to test the waters of emailing this list first to see how hard it is to push this "easier" issue. ;-) --Matt Delaney
