0

The MDN documentation of the CanvasRenderingContext2D.shadowBlur property states that

this value doesn't correspond to a number of pixels

Some other articles state that it is indeed in pixels, but I'm finding the MDN docs to be correct. Here is a PNG with an alpha channel, rendered on a canvas with shadowBlur set to 15:

canvas image shadowblur 15

And here is the same image rendered as an img element, with a -webkit-filter: drop-shadow() with the blur-radius value set to 15px:

enter image description here

It seems clear that the canvas blur is not in pixels, unless there's something wacky going on with Retina, or zoom level, or something else I'm not fully understanding right now.

If I drop the blur-radius on the drop-shadow() down to 5px, however, it's a pretty close match to the canvas:

enter image description here

So should blur-radius always be set to a third of shadowBlur to achieve parity? Could someone help me understand what's going on here?

alan
  • 870
  • 7
  • 24

1 Answers1

1

Problem

There is no defined unit as you state and the way shadow blur is implemented for canvas varies:

  • Currently for Firefox shadowBlur is 1/2 of CSS blur-radius.
  • Currently for Chrome shadowBlur is 1/4 of CSS blur-radius.

Though part of the reason is how the shadow is composited internally. Fire fox uses source-over, Chrome doesn't (which you need to compensate for with an extra doubling).

Looking at existing reports it is clear that this is an known issue, perhaps more on the non-technical side. For example, from the comments on this issue we can read:

The W3C canvas spec seems stale. The note in question was removed in September 2014 from HTML: https://html5.org/r/8813

If you want to get rid of shadows in these other modes, opening a new spec bug at https://whatwg.org/newbug might be a good start.

and in the next comment (my emphasis):

 #11 - currently Chrome complies the spec but Firefox draws a shadow as source-over as noticed. It's why two browsers show fundamental difference.

btw, I agree on shadow composition by only source-over. Currently shadow processing model is not too intuitive to understand for web developer.

So in conclusion, I guess we just have to sit and wait until W3C and the vendors can work this out and agree on the same method.

If you where to use 2x for Firefox and 4x for Chrome the shadow would of course "break" in the future if this gets fixed.

Solution

A possible workaround at the moment would seem to be to embed the shadow in the image itself, or produce a separate image for the shadow alone which then is composited manually.

Community
  • 1
  • 1