Bug 32708 - SVG filter on filter don't work
Summary: SVG filter on filter don't work
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 68469 26389
  Show dependency treegraph
 
Reported: 2009-12-18 03:56 PST by Dirk Schulze
Modified: 2014-05-12 05:54 PDT (History)
2 users (show)

See Also:


Attachments
SVG Filter on Filter (361 bytes, image/svg+xml)
2009-12-18 03:56 PST, Dirk Schulze
no flags Details
Patch (33.83 KB, patch)
2010-06-03 12:58 PDT, Dirk Schulze
zimmermann: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Schulze 2009-12-18 03:56:17 PST
Created attachment 45141 [details]
SVG Filter on Filter

If a parent object and it's child object use the same filter with the same filter id, none of the effects is drawn. This is caused by http://trac.webkit.org/browser/trunk/WebCore/rendering/SVGRenderSupport.cpp#L118.
The intention was to avoid two filter drawings on this combination: <text filter="url(#foo)">Test<tspan filter="url(#foo)">123</tspan></text>

Is this a regression, caused by the code clean-up on SVGRenderBase::prepareToRenderSVGContent()?
Comment 1 Dirk Schulze 2010-01-04 15:57:47 PST
I don't see a reason, why a tspan element shouldn't be rendered with a filter, if the text is rendered with the same filter? I couldn't find anythink about this strange behavior in the spec. Why should it only be possible that both, tspan and text, use filters, if the filters differ? Only batik and WebKit are doing this. I would like to delete this constraints if there is no plaussible reason to do that.
Comment 2 Nikolas Zimmermann 2010-01-04 17:38:04 PST
Hm interessting, I can't remember for which testcase this "hack" has been added, can you just try to delete the checks, and see what breaks?
Comment 3 Dirk Schulze 2010-01-15 14:28:57 PST
I run all svg tests and none of them break after deleting this check. There is still no reason for me to use this constraint beside to be compatible with batik. FF and Opera allow filters on text and tspan and also use them seperatly.
I'll write a patch with a simple test to get rid of this limitation.
Comment 4 Dirk Schulze 2010-06-03 12:58:22 PDT
Created attachment 57807 [details]
Patch
Comment 5 Eric Seidel (no email) 2010-06-03 13:25:42 PDT
Attachment 57807 [details] did not build on mac:
Build output: http://webkit-commit-queue.appspot.com/results/3013040
Comment 6 Dirk Schulze 2010-06-04 00:51:04 PDT
(In reply to comment #5)
> Attachment 57807 [details] did not build on mac:
> Build output: http://webkit-commit-queue.appspot.com/results/3013040

Sorry buildbot, but it doesn't look like it was my fault.
Comment 7 Nikolas Zimmermann 2010-06-04 02:43:19 PDT
Comment on attachment 57807 [details]
Patch

r=me, mac ews has a problem unrelated to your patch "distccd[37387] (dcc_writex) ERROR: failed to write: No space left on device".
Please change the text to "This is for filter on filter", instead of "This is a for filter on filter" before landing :-)
Comment 8 Eric Seidel (no email) 2010-06-04 10:34:04 PDT
(In reply to comment #7)
> (From update of attachment 57807 [details])
> r=me, mac ews has a problem unrelated to your patch "distccd[37387] (dcc_writex) ERROR: failed to write: No space left on device".
> Please change the text to "This is for filter on filter", instead of "This is a for filter on filter" before landing :-)

?

Really?  the mac-ews bot is only using 13% of its disk.  Maybe one of the other machines in teh cluster is out of space?
Comment 9 Eric Seidel (no email) 2010-06-04 10:35:20 PDT
Thanks.  I've notified the admin of that machine and it shoudl be fixed soon.
Comment 10 Dirk Schulze 2010-06-04 11:02:38 PDT
Committed r60689: <http://trac.webkit.org/changeset/60689>