Last Comment Bug 455986 - SVG filters feImage with xlink:href doesn't work with fragments
: SVG filters feImage with xlink:href doesn't work with fragments
Status: NEW
: dev-doc-needed
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 21 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.w3.org/Graphics/SVG/Test/2...
: 703987 882434 1215575 (view as bug list)
Depends on: 272288 390379
Blocks: 311029 410761 svg11tests 1262352
  Show dependency treegraph
 
Reported: 2008-09-18 19:00 PDT by Hans Schmucker
Modified: 2016-05-07 11:46 PDT (History)
25 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wanted


Attachments
Testcase for feImage xlink:href document fragment bug. (616 bytes, image/svg+xml)
2008-09-18 19:01 PDT, Hans Schmucker
no flags Details

Description Hans Schmucker 2008-09-18 19:00:03 PDT
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-
Comment 1 Hans Schmucker 2008-09-18 19:01:02 PDT
Created attachment 339387 [details]
Testcase for feImage xlink:href document fragment bug.
Comment 2 Martin Hejral 2008-09-21 23:27:17 PDT
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 3 Robert Longson 2008-09-27 01:07:03 PDT
This is really just another example of bug 272288.
Comment 4 Robert Longson 2008-12-29 02:31:11 PST
Confirming, although this is likely to simply be marked as a a duplicate of bug 272288 eventually.
Comment 5 Daniel Holbert [:dholbert] (largely AFK until June 28) 2010-09-21 09:10:06 PDT
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 Daniel Holbert [:dholbert] (largely AFK until June 28) 2010-09-21 09:15:32 PDT
(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).
Comment 7 Daniel Holbert [:dholbert] (largely AFK until June 28) 2011-11-21 10:32:07 PST
*** Bug 703987 has been marked as a duplicate of this bug. ***
Comment 8 Michael Mullany 2013-05-24 14:07:19 PDT
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 9 Robert Longson 2013-06-13 01:08:47 PDT
*** Bug 882434 has been marked as a duplicate of this bug. ***
Comment 10 Michael Mullany 2013-06-13 12:06:28 PDT
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 11 Chris Masters 2013-12-10 13:34:51 PST
I would also like to add my support to resolving this issue.

I'm really sorry I do not have the technical proficiency to help fix it but as more and more people turn to SVG as a non-resolution dependent graphics format it is a real tragedy that Firefox does not allow the use of feImage with a document fragment. It restricts the use of using many filter options and Michael Mullany has said, is now the only modern browser without this support.
Comment 12 Robert Longson 2013-12-10 17:45:17 PST
Please try to resist commenting unless you are interested in fixing it. There is a voting mechanism you can use to express support if not.
Comment 13 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2014-05-15 14:26:39 PDT
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?
Comment 14 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2014-05-15 14:31:23 PDT
I think I would implement this in a way similar to the way -moz-element is implemented. nsImageRenderer in nsCSSRendering implements that.
Comment 15 James 2014-05-15 14:38:11 PDT
having used this property extensively, they definitely do handle dynamic updates to the referenced image. In one of my cases its a group of svg paths, this group gets periodically added to and also the paths them selves get points added to them in realtime.. it all updates correctly in safari/chrome, and fast.
ForeignObject is a good question.. obviously if combined with canvas, then canvas turned to png, it could be used to read the image values of some sections of the dom that are not allowed for cross origin or for user privy reasons ( visited links for example ), tho i assume that canvas that reference svg that have foreign object already can be turned to a png
As for having a circular reference, this is also a good question.. care must be taken not to either crash the browser or make it totally un responsive.. tho circular references can exist in css for example ( you can make an item which moves when hovered, then moves out of hover when you do then back in etc.. it will jump about like mad.. ) so maybe this should behave the same, every time the frame is updated it recalls, giving a new view based on the total calculation of the last, or maybe it should just not allow a circular reference ..
Comment 16 Michael Mullany 2014-05-15 14:42:32 PDT
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
Comment 17 James 2014-11-01 11:27:49 PDT
Wonderful to finally see this feature implemented in Firefox! I have been trying it out and it mostly works as advertised.

I initially thought that dynamic changes to the source of the feImage did not get reflected in the resulting filter image, but this is only the case when changing the dom from the dev tools. If you make changes from the dev tools it behaves inconsistently, but if you script updates to the source image via javascript it seems to perform fine. This may well be a nightly dev tools but however and not related to feImage.

The second strange behavior seem to be when applying a filter with an feImage to a non rectangular shape, or at least a circle.

The svg from Michael Mullany above at http://codepen.io/mullany/pen/rKLdJ displays corrector in chrome / safari but shows nothing in firefox nightly! i tried simplifying the solution and tracked it down to applying filters with feImage to circles. It also behaves oddly with polygon's too.
Comment 18 Robert Longson 2015-05-31 23:41:40 PDT
Beware comment 17, its wrong, this feature hasn't been implemented. If it had, this bug would be marked fixed rather than new.
Comment 19 James 2015-06-02 17:26:13 PDT
In my testing, it did work as expected when trying the attached "Testcase for feImage xlink:href document fragment bug" in firefox, tho the test case is not that clear how it works .. i tried again and it still seems to behave as i would expect if the feature worked .. it defiantly does not work for non rectangular elements tho. 
This is a feature i and a lot of other keen SVG developers would love to see working reliably however!
Comment 20 Robert Longson 2015-10-16 21:32:44 PDT
*** Bug 1215575 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.