Re: Fwd: Property to disable SVG filters

Jeff,

I think think using a featurestring like you indicate here is a reasonable  
way forward, if used correctly. It's also a good way to test new features  
without breaking the specs. I can see how it doesn't help against existing  
content however, and that might be an argument for the 'filter-rendering'  
property. I think having a '-moz-filter-rendering' property would be ok,  
as long as there is no 'moz-filter-rendering' attribute in content without  
being namespace-prefixed.

I'm willing to consider adding feature-strings for the potentially more  
processing-intense filter primitives for the 1.2 filter spec. Note however  
that there is an SVG 1.1 Basic filter module [1] already (and a  
corresponding feature-string), and that it excludes for example  
feConvolveMatrix.

I'm slightly worried that by having people opt-in with the  
'filter-rendering' property we are destroying future optimization  
possiblities since people could start using the 'optimizeQuality' instead  
of 'auto' to get consistent visual results in all current viewers.  
Obviously that's an argument for using the '-moz' prefixed variant instead.

Cheers
/Erik

[1] http://www.w3.org/TR/SVG11/filters.html#basic-filter-mod

On Wed, 23 Jan 2008 18:44:09 +0100, Jeff Schiller <codedread@gmail.com>  
wrote:

>
> Tim,
>
> I agree with Doug, make it a Firefox-specific feature string.  Authors
> who want filters should be providing fallback content already, so they
> can extend that mechanism.  Feature strings and
> requiredFeatures/switch are the way of testing for feature support in
> SVG so it makes sense to extend that and not a custom attribute.
>
> <switch>
>   <rect fill="#someFilter"
> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Filter" />
>   <rect fill="#someFilter"
> requiredFeatures="http://www.mozilla.org/SVG/feature#Filter" />
>   <rect fill="blue" />
> </switch>
>
> In this scenario, Firefox 3 should specifically NOT enable the
> standard SVG filter feature string (so that authors who aren't aware
> of Fx3's poor filter performance don't inadvertently trigger filter
> usage in Fx3).
>
> Regards,
> Jeff
>
> On 1/23/08, Tim Rowley <tor@acm.org> wrote:
>>
>> 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
>>
>> There is also some discussion in the following bug:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=413588
>>
>> 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
>> property as follows:
>>
>> '-moz-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.
>>
>> How does the SVG WG and other implementor feel about this?  If it's
>> acceptable to the WG, we could remove the -moz- property prefix.
>>
>> We'd appreciate an answer to this issue soon, as we're about a week
>> from code freeze.
>>
>>
>



-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 24 January 2008 15:44:25 UTC