10647 2010-09-17 18:01:56 +0000 shadowBlur should be linear throughout rather than changing to sqrt() above 8px 2010-10-05 12:58:56 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML Canvas 2D Context (editor: Ian Hickson) unspecified All All RESOLVED FIXED P2 normal --- 1 dbaron ian annevk ap ayg excors former-z^corpan ian jackalmage mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 39088 0 dbaron 2010-09-17 18:01:56 +0000 http://www.w3.org/TR/2010/WD-2dcontext-20100624/#dom-context-2d-shadowblur says, in point 4.1: If shadowBlur is less than 8, let σ be half the value of shadowBlur; otherwise, let σ be the square root of multiplying the value of shadowBlur by 2. This is bizarre behavior that's emulation of a bug in Safari for Mac. It doesn't seem present in Chromium for Linux, and until very recently the implementation of it in Gecko was actually wrong by a factor of sqrt(2) for the >8px case because the *2 inside the sqrt() was missing. No Gecko bugs were filed about this difference; I only noticed because I was changing our blur code to conform to css3-background. Instead of this bizarre formula, I think it should instead define σ as half the value of shadowBlur, no matter what the value of shadowBlur. This would match css3-background's definition of blur for box-shadow. Given the current lack of interoperability, I don't think changing this would pose a problem, and it would be much better to have a sensible behavior that's consistent with other specifications. I have a testcase at http://dbaron.org/css/test/2010/shadow-blur ; the example on the left is box-shadow and the example on the right is canvas. 39828 1 ian 2010-09-28 23:14:20 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 39829 2 contributor 2010-09-28 23:16:58 +0000 Checked in as WHATWG revision r5538. Check-in comment: Change how canvas blur is calculated to be less quirky. Please update your browsers accordingly. This affects all implementations. http://html5.org/tools/web-apps-tracker?from=5537&to=5538 39996 3 ayg 2010-09-29 18:57:04 +0000 (In reply to comment #0) > This is bizarre behavior that's emulation of a bug in Safari for Mac. It > doesn't seem present in Chromium for Linux, and until very recently the > implementation of it in Gecko was actually wrong by a factor of sqrt(2) for the > >8px case because the *2 inside the sqrt() was missing. No Gecko bugs were > filed about this difference; I only noticed because I was changing our blur > code to conform to css3-background. FWIW, there was a bug filed about this: https://bugzilla.mozilla.org/show_bug.cgi?id=578995 This change makes a lot of sense, though. Actually, I already suggested it in bug 10169, but I'm not an implementer, so it didn't get anywhere. (Which is fine, although I should have prodded implementers about it as I said I would . . .)