SVG filters feImage with xlink:href doesn't work with fragments
Categories
(Core :: SVG, defect)
Tracking
()
Tracking | Status | |
---|---|---|
status2.0 | --- | wanted |
People
(Reporter: hansschmucker, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: dev-doc-needed)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080916043910 Minefield/3.1b1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080916043910 Minefield/3.1b1pre The feImage filter is supposed to support document fragments (see http://www.w3.org/TR/SVG/filters.html#feImage ), including but not limited to fragments of the current document, in practice emulating the "use" element and rendering the output to the current buffer. Basically, this deprives SVG filters of any way to work with dynamic data, like canvas and instead forces webdevelopers to instead use very slow JS implementations of those filters. For example, to recreate the old Java "waves" demo, the canvas could be fed into an feDisplacement filter. Reproducible: Always Steps to Reproduce: 1. Open the attached testcase in Firefox 2. Open it again in Inkscape Actual Results: Firefox doesn't display the green rectangle inserted into the rendering chain through an feImage. Output of Inkscape and Firefox differ. Expected Results: The green rectangle should be added to the rendering via the feImage filter, overlaying the red background-
Reporter | ||
Comment 1•16 years ago
|
||
Reporter | ||
Updated•16 years ago
|
Reporter | ||
Updated•16 years ago
|
Comment 2•16 years ago
|
||
I can confirm this bug in Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Comment 4•16 years ago
|
||
Confirming, although this is likely to simply be marked as a a duplicate of bug 272288 eventually.
Updated•15 years ago
|
Updated•15 years ago
|
Comment 5•14 years ago
|
||
To get this to work (for <feImage xlink:href="#idOfSomeElement">), I think we actually need to import the <use> behavior for into <feImage>, right? (to clone a subtree, or at least generate the document with that subtree if the targeted ID is in a different document) We could almost fall back on moz-element here, except that the targeted element could be in a completely different document from the one we're displaying (e.g. xlink:href="foo.svg#SomeNodeID"), and IIUC, -moz-element only works for elements in the same document. Still, we might be able to take advantage of some of moz-element's underlying mechanics.
Comment 6•14 years ago
|
||
(In reply to comment #3) > This is really just another example of bug 272288. I think this is actually distinct from bug 272288 (which is about <image>) -- this bug is about using fragment IDs, and the <image> tag doesn't accept those... > Unlike ‘use’, the ‘image’ element cannot reference elements within an SVG file. http://www.w3.org/TR/SVG/struct.html#ImageElement ...whereas the <feImage> tag does accept fragment IDs (as noted in comment 0).
Updated•14 years ago
|
Comment 8•11 years ago
|
||
It might be time for someone to work on this. Safari and Chrome(Canary) as well as IE now support importing document fragments correctly into filter streams. aka http://codepen.io/mullany/pen/rKLdJ Now displays correctly except in Firefox.
Comment 10•11 years ago
|
||
There will be increasing interest in blending modes since they are heavily used in the iOS7 visual style. Because of the lack of support for enable-background in every browser except IE10, the only way to achieve these effects in SVG is to use document fragments via feImage. And Firefox is now the only browser that doesn't support these.
Comment hidden (me-too) |
Comment hidden (obsolete) |
Do the other browsers handle dynamic changes to the referenced content updating the filter? What do they do if the referenced content itself uses the filter? Do they handle <foreignObject> content inside the referenced content subtree?
I think I would implement this in a way similar to the way -moz-element is implemented. nsImageRenderer in nsCSSRendering implements that.
Comment hidden (off-topic) |
Comment 16•10 years ago
|
||
Other use cases for feImage fragments: If you want to do a linear focus blur on text then you need to be able to get a gradient into your filter chain in some way. If you want to do distortion effects on text then it's handy to import linear and radial gradients as displacement inputs. Other browsers update the in-filter feImage when the referenced object is updated. Erik Dahlstrom's ripple distortion effect is a good demo: http://svg-wow.org/filterEffects/ripple.svg
Updated•10 years ago
|
Comment hidden (off-topic) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•8 years ago
|
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment 25•3 years ago
|
||
I'm adding the note to the BCD for feImage to the xlink:href variable to cover this case.
""notes": "Document fragments (including references to fragments in current document) are not supported (see <a href='https://bugzil.la/455986 '>bug 455986</a>).""
- Does the bug also apply to
href
(or justxlink:href
)? - Would this also impact SVGFEImageElement and if so, how? (i.e. can't see an href or xlink:href variable).
- Is there a better way to describe the above note?
Comment 26•3 years ago
|
||
- yes, both.
- That page says that SVGFEImageElement implements the properties of SVGURIReference so we do document that already.
- sure that seems fine.
Updated•3 years ago
|
Comment 28•3 years ago
|
||
I gave this a shot, but it is a bit harder than it seems...
Apart of the hard-coded intrinsic sizes and such (which obviously would
need to be fixed), the main issue is that we query filter bounds from
layout, to compute overflow rects, but:
-
SVGFEImageElement::GetPrimitiveDescription works by querying the
filter surfaces, which need painting, and we shouldn't start painting
from layout. So we'd need a way to query filter bounds without a
full-fledged GetPrimitiveDescription, which I don't know how hard is
it. -
The target element might not be reflowed yet, so we might not know
its bounds (we might get away with only supporting some SVG frames we
know the intrinsic dimensions of).
With that fixed, something like this ought to do, but that's not quite
easy to fix...
Updated•2 years ago
|
Comment 29•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 24 votes.
:jwatt, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 30•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Comment 32•5 months ago
|
||
This is something that's needed in order to recreate the diagonal slice offset effect with an SVG filter. It's a pretty simple effect if feImage
can reference the diagonal stripes SVG element (works in Chrome and Safari, but not in Firefox) and then the result of this feImage
can be used as a displacement map (works in Safari, but not in Chrome).
Comment 33•5 months ago
|
||
No it isn't. Pretty much anything you can do with an internal SVG feImage, you can also do with an external standalone feImage and those are supported by all browsers.
Comment 34•5 months ago
|
||
Using an external standalone feImage is very rarely an affordable option. In this particular case, it's out of the question.
Comment 35•5 months ago
|
||
OK, use a data URL then.
Comment 36•5 months ago
|
||
(In reply to Robert Longson [:longsonr] from comment #35)
OK, use a data URL then.
That is easier said than done.
Image showing how Firefox fails to render an feImage with a Data URI, while Chrome succeeds with both a Data URI and Document Fragment.
SVG Dot Filter with feImage Document Fragment CodePen
SVG Dot Filter with feImage Data URI CodePen
Below is a snippet of the original filter that I was working on that used feImage
:
<circle id="dot" cx="5" cy="5" r="5" fill="blue" />
<!-- ... -->
<feImage x="0" y="-1" width="10" height="11" href="#dot" id="hmm" />
I attempted your solution of just using a Data URI, but Firefox does not support Data URIs in an feImage
's href
(Chrome does support this):
<feImage x="0" y="-1" width="10" height="11" href='data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10"><circle id="dot" cx="5" cy="5" r="5" fill="blue" /></svg>' id="hmm" />
I also tried to find another way to use a Data URI to achieve my goal in my CodePen but was repeatedly unsuccessful. So, Robert, I don't think it's as simple as "use a Data URI then," which does come off as very dismissive of the huge roadblock that is Firefox lacking feImage
Document Fragment support.
Comment 37•5 months ago
|
||
Your data URL just needs height and width values on the root element. E.g.
<feImage x="0" y="-1" width="10" height="11" href='data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10" height="10" width="10"><circle id="dot" cx="5" cy="5" r="5" fill="blue" /></svg>' id="hmm" />
Comment 38•5 months ago
|
||
Ah, my apologies, that small portion appears to be irrelevant, but I believe my point still stands. In fact, even applying that the rendering between Chrome and Firefox still differs greatly here. Image showing the difference between Chrome and Firefox.. And that could be caused by another bug or not, I don't know. But that furthers my point that it's not so simple and expecting everyone to learn each Firefox bug rather than advocate for fixing the bugs is, I feel, an unhelpful viewpoint.
Description
•