Closed Bug 413588 Opened 17 years ago Closed 10 years ago

Property to disable SVG filters

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: tor, Unassigned)

Details

There is some thought that Mozilla's current implementation of SVG filters are too slow, and that they should be disabled by default in order not to scare content developers from ever using this feature in the future: http://groups.google.com/group/mozilla.dev.tech.svg/browse_thread/thread/807b7c2f75a0b13e If we decide to do this, people seem to be gravitating towards the proposal put forward by Ken Stacey to add a -moz-filter-rendering (or just filter-rendering if the SVG WG agrees with the proposal) property as follows: 'filter-rendering' Value: auto | optimizeSpeed | optimizeQuality | inherit Initial: auto Applies to: container elements, graphics elements Inherited: yes In Firefox 3, we'd treat auto = optimizeSpeed = pretend we don't implement filters and render the geometry unfiltered. We also need to consider what to with the filter feature strings - do we advertise filters to content when by default they would be disabled? Personally I don't think adding this property is the right thing to do. Content can stretch various parts of the SVG implementation and suffer performance problems - why single out this one feature? Only a subset of the filters are very slow, and even those are useful when used in a static context. Disabling filters seems like a bad idea from an interoperability point of view, since content designed around filters generally won't degrade gracefully without them.
(In reply to comment #0) > Personally I don't think adding this property is the right thing to do. > Content can stretch various parts of the SVG implementation and suffer > performance problems - why single out this one feature? Because it's a lot slower than any other feature in typical use AND we expect performance to get orders of magnitude better if/when we get GPU acceleration. > Only a subset of the > filters are very slow, and even those are useful when used in a static context. Even things like scrolling, or repainting during incremental load, trigger the paint path and can cause horrible performance problems. > Disabling filters seems like a bad idea from an interoperability point of > view, since content designed around filters generally won't degrade gracefully > without them. How is it different from the situation in FF2 where we just didn't support them? IMHO we shouldn't advertise the feature strings in FF3.
Is most use of SVG filters essential to the image or just a minor touch? If it's the former, I think it's better to show the content slowly than totally screw up the rendering.
It's both/either. The thing is, FF2 and Safari 3 already display SVG content with filters ignored. So continuing to do that doesn't create any new problems. > better to show the content slowly? How about this slowly? http://ejohn.org/files/ecma-cloud.svg there's "sluggish" and then there's "my browser hung"
Is it acceptable for auto to enable filter elements which use the fast primitives and only disable filters with slow primitives? Can the slow primitives be sped up (enough) by using a lower resolution ?
As far as I can tell only 3 filters are slow. feGaussianBlur feTurbulence - gets linearly slower as numOctaves increases, 0 and 1 could be considered fast feMorphology - gets slower as order increases, the default of "3" is pretty slow, perhaps only 1 could be considered fast. Unfortunately feGaussianBlur as used by ecma-cloud.svg seems to be one of the most popular filters for SVG content.
(In reply to comment #3) > How about this slowly? > http://ejohn.org/files/ecma-cloud.svg > there's "sluggish" and then there's "my browser hung" That's probably not just filter slowness, but an invalidation loop problem (bug 41155).
(In reply to comment #6) > (In reply to comment #3) > > How about this slowly? > > http://ejohn.org/files/ecma-cloud.svg > > there's "sluggish" and then there's "my browser hung" > > That's probably not just filter slowness, but an invalidation loop problem (bug > 41155). That should have been bug 411555.
That solution requires authors to use <switch>, so it's an opt-out solution which I think is not very helpful in practice. Can we just have this filter-rendering property, and make "auto" disable the filters named in comment #5, and make optimizeSpeed disable all the non-trivial ones?
Also, don't all filters require expensive X server round-trips on Linux? Shouldn't feConvolveMatrix and the lights be on the slow list?
As others have stated, authors who don't use the switch element are going to see some mighty screwed up results in their images, particularly in Safari and Firefox 2-. In my opinion, that's their own fault, they need to test if filters are supported.
Well yes, so your suggestion is OK, but it's not enough.
(In reply to comment #10) > Also, don't all filters require expensive X server round-trips on Linux? No - we render things that we will be applying filters to into an image surface (saves round-tripping the server, loses any potential hardware acceleration). > Shouldn't feConvolveMatrix and the lights be on the slow list? Lights probably go in the slow category. Convolve probably goes on the "medium" pile.
I think that restricting the filterRes would be the best answer. Give each filter a GetMaxFilterRes method. Then loop through the filters in the filter chain and determine the maximum filterRes. Each filter could have an algorithm to return whatever you wanted as the maximum resolution and taking into account the individual filter attributes. That way you always see something approaching what you want even if there might be some pixellation. You could certainly combine this with filter-rendering if you wish so that GetMaxFilterRes stuff is only called for filter-rendering auto and maybe optimize-speed gives you an even smaller maximum filter res.
I like the idea of controlling filterRes, we wouldn't need filter-rendering with that scheme. Instead of capping the maximum we could just choose the default filterRes carefully, since most authors are actually not going to specify it. The only issue I can see is feConvolveMatrix, where the rendering really depends on filterRes. I'm not sure what to do about that.
(In reply to comment #6) > (In reply to comment #3) > > How about this slowly? > > http://ejohn.org/files/ecma-cloud.svg > > there's "sluggish" and then there's "my browser hung" > Performance should have improved to "really slow" now that the patch for bug 411555 is in.
I filed bug 414784 on an optimization that should improve SVG performance massively on that wretched World of Ecmascript test.
Is this now a WONTFIX then?
I still think it would be useful to be able to selectively turn off filters when the implementation is relatively slow. However, we don't need to fix this for 1.9 anymore.
We've not needed this so far. Probably too late to stick the genie back in the bottle now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.