Bug 58100 – 1px box-shadow looks ugly

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Simon Fraser (smfr)]

Box-shadow with a 1px blur radius looks ugly, and rather different from a CG 1-px shadow.

[Simon Fraser (smfr)]

Created attachment 88740 [details]
Testcase

[Martin Robinson]

I wonder if this is due to the fact that ShadowBlur/ContextShadow does not yet support fractional blur radii.

[Simon Fraser (smfr)]

I'm sure it is.

[Simon Fraser (smfr)]

<rdar://problem/9076329>

[Simon Fraser (smfr)]

The code is buggy for 1px radii. For an input of:


000 000 000 000 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 000 000 000 000 

the results are

043 070 088 079 061 
069 112 141 127 098 
096 154 194 175 135 
105 169 212 191 148 
105 169 212 191 148 
105 169 212 191 148 
096 154 194 175 135 
078 126 159 143 111 
060 098 123 111 086 

which is not symmetrical. For radii >=2 this problem does not happen.

[Dirk Schulze]

I could compare the both shadows (ContextShadow and ShadowBlur) and the result of ContextShadow looked more sane. It also did not have big problems with 0-1px shadows. Is there a difference in the implementation?

[Simon Fraser (smfr)]

Context Shadows's code gives:

Blur source:
000 000 000 000 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 255 255 255 000 
000 000 000 000 000 

Blur result:
086 111 123 098 060 
111 143 159 126 078 
135 175 194 154 096 
148 191 212 169 105 
148 191 212 169 105 
148 191 212 169 105 
135 175 194 154 096 
098 127 141 112 069 
061 079 088 070 043 

which is still incorrect, but different (not sure why).

[Simon Fraser (smfr)]

If I add 1px of padding so that the edge alpha is always zero, the issue goes away. I'll do that.

[Simon Fraser (smfr)]

Created attachment 91539 [details]
Patch

[Dirk Schulze]

Comment on attachment 91539 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91539&action=review

Can you please check if the pixel results for feDropShadow changed (they should) and update them? They are located at LayoutTests/svg/filter/feDropShadow.svg and LayoutTests/dynamic-updates/

r- for the test and the and the missing result updates. The fix itself looks good to me. If I should be wrong with tests just add a comment.

> LayoutTests/fast/box-shadow/single-pixel-shadow.html:15
> +      -webkit-transform-origin: -1px -1px;
> +      -webkit-transform: scale(20);

Do you really want a pixelation here? On SVG we try to avoid this and transform all affected objects to devicespace and apply shadows afterwards. So we always have a goof looking shadow. This definitely does not belong to this big. But if it gets changed in the future, the text would be useless. Have you checked what Firefox or Opera are doing? But I don't have an idea how to make a pixel with it. What about canvas? Is canvas using shadow? If you draw a shadow on canvas it should be pixelated on scaling, also in the future, no?

[Dirk Schulze]

Comment on attachment 91539 [details]
Patch

Talked with Simon on IRC. We don't see a way to have constant results on shadows across platforms as long as not all platforms are using ShadowBlur. Even if we get resolution independent shadows, we should see if the shadow is broken, since the shadow radius gets scaled as well. Simon updates filter results on landing.

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/85299