Bug 32346 – SVG property -webkit-shadow should apply shadow on the result after compositing

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Beth Dakin]

* STEPS TO REPRODUCE
1. create an svg shape with stroke (preferably, thick stroke) and solid fill
2. apply -webkit-shadow on the <svg> container

* RESULTS
Currently, the shadows are applied seperately to the stroke and fill

*EXPECTED RESULTS
The shadow should apply to the composite of the stroke and fill

<rdar://problem/7389404>

[Beth Dakin]

Created attachment 44563 [details]
Patch

Patch!

Comment on attachment 44563 [details]
Patch

I wonder if this can’t be done more efficiently:
1) Clip to the bounding box (perhaps adjusted to encompass the shadow?) before beginning the transparency layer, to get the layer to have the optimal size (like we do for opacity)
2) If we have both opacity and a shadow, use a single transparency layer for both (perhaps requires multiplying the shadow’s alpha by the opacity?)

[Beth Dakin]

Created attachment 44589 [details]
New patch

Here's a new patch that addresses Dan's comments. I clipped the transparency layer to the size of the shadow, but I was not able to use a single transparency layer for both opacity and shadows. When I tried to use a single layer, the color of the shadow (which *was* at the correct alpha level) was visible behind the partially-transparent fill color. This seems wrong since it is not the behavior of box-shadow.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44589 [details] without any errors.

[Beth Dakin]

Fixed with r51936.

[Dirk Schulze]

*** Bug 30930 has been marked as a duplicate of this bug. ***

[Dirk Schulze]

Just noticed, that this patch does not fix the shadow problem on Gtk.

[Beth Dakin]

In the CG, transparency layers specifically apply to shadows. The CG documentation says:

"After the transparency layer is ended, the result is composited into the context using the global alpha and shadow state of the context. "

My guess is that the same is not true for the GTK-equivalent. We may need a fancier solution there.

[Dirk Schulze]

(In reply to comment #8)
> In the CG, transparency layers specifically apply to shadows. The CG
> documentation says:
> 
> "After the transparency layer is ended, the result is composited into the
> context using the global alpha and shadow state of the context. "
> 
> My guess is that the same is not true for the GTK-equivalent. We may need a
> fancier solution there.

On Gtk we draw the shadow just a moment before we have a drawing operation (fillPath, strokePath, drawPath, drawImage, drawLine, ...) independent of the transparency layer.
A partly fix would be to solve bug 6564 and use drawPath to draw the stroke and fill at once. This won't fix shadows on stroked/filled texts and stroked images on SVG.

I think Qt has the same problem and I don't know how the shadow system of Skia works.

[Dirk Schulze]

T(In reply to comment #3)
> Created an attachment (id=44589) [details]
> New patch

The patch is responsible for a regression on svg/filters/shadow-on-rect-with-filter.svg.

[Beth Dakin]

Oh no! I see it now. The test fails in the pixel test only. Looks like the bounding box is clipping away far too much here. opacity has the same problem actually; in other words, if you replace the shadow style in that test case with "opacity: 0.5," we clip too much in the same way. This deserves a new bug report, especially since it is not unique to this patch or shadows. Filing one now.

[Beth Dakin]

Filed https://bugs.webkit.org/show_bug.cgi?id=32584

[Eric Seidel (no email)]

Attachment 44589 [details] was posted by a committer and has review+, assigning to Beth Dakin for commit.

[Eric Seidel (no email)]

Looks like this was already landed as r51936.