|Summary:||SVG filter on filter don't work|
|Product:||WebKit||Reporter:||Dirk Schulze <krit>|
|Version:||525.x (Safari 3.1)|
|OS:||OS X 10.5|
|Bug Depends on:|
|Bug Blocks:||68469, 26389|
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 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 (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 (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.