SVG filters
rocal...@gmail.com
situations but it's very easy to do simple things that will slow page
redraws to a crawl, effectively making the page/browser unusable. We
can speed filters up a lot --- probably by several orders of magnitude
with GPU programming --- but really only post-FF3. In the meantime I
think we run the risk of poisoning the feature for authors; they'll be
forced to use filters minimally or not at all to avoid harming FF3
users.
We could just disable all filters on trunk but that would stop authors
from using them even where FF3 will handle them just fine. As an
alternative, here's a wild idea: add a new custom attribute to the
<svg> element, "mozEnableSlowFilters", which basically means filters
should be enabled no matter how slow they are. Thoughts?
Rob
Question
3.0Gcomputer if it's working in a transparent window.
I don't know the details about how it's working, but I think maybe in FF3 I
will not use it. I don't like to have an attribute like
"mozEnableSlowFilters", because it may be abandoned some day and it's not a
standard. Any way, if you do finnished it like this, well, it's also
accepatble. :-) This is my opinion as an application developer.
Annnnnnnnnnd, I really think animation has the higher priority. Flash now
has its as3 engine, but moz SVG is still waiting... (for javascript 2.0 or
something else?)
Even we all like SVG,Do you think SVG has a bright future while comparing
with flash ?
> _______________________________________________
> dev-tech-svg mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-svg
>
--
>: ~
rocal...@gmail.com
> I don't like to have an attribute like
> "mozEnableSlowFilters", because it may be abandoned some day and it's not a
> standard.
The point is that in FF4 or whenever we have fast filters (possibly a
run-time decision based on whether a GPU is available) we'll enable
filters always regardless of whether that attribute is set. So we
don't expect authors to always use it and we don't need it to be part
of an official standard.
> Annnnnnnnnnd, I really think animation has the higher priority. Flash now
> has its as3 engine, but moz SVG is still waiting... (for javascript 2.0 or
> something else?)
> Even we all like SVG,Do you think SVG has a bright future while comparing
> with flash ?
Yeah actually I do. You can mix HTML with (and especially inside) SVG
in very interesting ways. AIR can do some of that but Flash-in-the-
browser really can't, not without massive changes to the plugin API
which would amount to a pretty deep integration of Flash with the
browser itself.
Rob
Doug Schepers
rob...@ocallahan.org wrote (on 1/2/08 8:03 PM):
I think something like that might be a good idea. That way, authors
could still use filters, as long as they are careful, and the content
will still work in other viewers and in future versions of FF.
I might suggest it could be a featurestring, instead, though... that
way, it could be used in a <switch> element with fallback content (such
as a gradient, or even a simpler filter).
I'll bring this up at tomorrow's SVG telcon, and see what others think.
I don't think Erik Dahlstrom, the Filters Module spec editor, will be
there (he's still on vacation), but others may wish to chime in. What
is a reasonable timeline for you on this? We want to be you to have
time to implement what we all come up with.
Regards-
-Doug
rocal...@gmail.com
> rob...@ocallahan.org wrote (on 1/2/08 8:03 PM):
> > from using them even where FF3 will handle them just fine. As an
> > alternative, here's a wild idea: add a new custom attribute to the
> > <svg> element, "mozEnableSlowFilters", which basically means filters
> > should be enabled no matter how slow they are. Thoughts?
>
> I think something like that might be a good idea. That way, authors
> could still use filters, as long as they are careful, and the content
> will still work in other viewers and in future versions of FF.
Yeah. But more importantly, when FF4 (or whatever) is out with hot new
GPU-based filters, authors will be able to use filters with impunity.
> I might suggest it could be a featurestring, instead, though... that
> way, it could be used in a <switch> element with fallback content (such
> as a gradient, or even a simpler filter).
That sounds like more work for authors, especially given that this is
just a temporary hack probably.
> I'll bring this up at tomorrow's SVG telcon, and see what others think.
> I don't think Erik Dahlstrom, the Filters Module spec editor, will be
> there (he's still on vacation), but others may wish to chime in. What
> is a reasonable timeline for you on this? We want to be you to have
> time to implement what we all come up with.
It would be good to have more feedback. You might even decide that
this would be a generally useful thing to standardize.
Rob
Doug Schepers
rob...@ocallahan.org wrote (on 1/2/08 11:12 PM):
>
>> I might suggest it could be a featurestring, instead, though... that
>> way, it could be used in a <switch> element with fallback content (such
>> as a gradient, or even a simpler filter).
>
> That sounds like more work for authors, especially given that this is
> just a temporary hack probably.
Sure, more work, but not a lot more work. As someone who's used filters
a fair bit, I can say that content that's designed to look good with a
filter rarely looks good without it. For the most part, the content
creator would want to supply a fallback anyway.
But it doesn't have to be more work, really. It might just be as simple
a matter of putting the featurestring on a <switch> child rather than on
the root, as you suggested.
>> I'll bring this up at tomorrow's SVG telcon, and see what others think.
>> I don't think Erik Dahlstrom, the Filters Module spec editor, will be
>> there (he's still on vacation), but others may wish to chime in. What
>> is a reasonable timeline for you on this? We want to be you to have
>> time to implement what we all come up with.
>
> It would be good to have more feedback. You might even decide that
> this would be a generally useful thing to standardize.
There are lots of instances where I would like to gracefully degrade in
the face of limited resources, and this might well be one of those.
Regards-
-Doug
rocal...@gmail.com
> rob...@ocallahan.org wrote (on 1/2/08 11:12 PM):
> >> I might suggest it could be a featurestring, instead, though... that
> >> way, it could be used in a <switch> element with fallback content (such
> >> as a gradient, or even a simpler filter).
>
> > That sounds like more work for authors, especially given that this is
> > just a temporary hack probably.
>
> Sure, more work, but not a lot more work. As someone who's used filters
> a fair bit, I can say that content that's designed to look good with a
> filter rarely looks good without it. For the most part, the content
> creator would want to supply a fallback anyway.
>
> But it doesn't have to be more work, really. It might just be as simple
> a matter of putting the featurestring on a <switch> child rather than on
> the root, as you suggested.
Actually, are you suggesting that the default should be that FF3
renders filters, and authors can add <switch> markup to opt out of FF3
if they find its filters too slow? I think that's probably a mistake.
Most of the time it will be too slow, so the default should be that
FF3 does not render filters.
Rob
Doug Schepers
rob...@ocallahan.org wrote (on 1/2/08 11:45 PM):
>>
>> But it doesn't have to be more work, really. It might just be as simple
>> a matter of putting the featurestring on a <switch> child rather than on
>> the root, as you suggested.
>
> Actually, are you suggesting that the default should be that FF3
> renders filters, and authors can add <switch> markup to opt out of FF3
> if they find its filters too slow? I think that's probably a mistake.
> Most of the time it will be too slow, so the default should be that
> FF3 does not render filters.
No, I agree that would be better to have authors opt-in, rather than
opt-out. I can probably express myself better in pseudo-code.
You suggest something like the following:
<svg ... mozEnableSlowFilters="true">
<filter id="myFilter">
...
</filter>
<path filter="url(#MyFilter)" ... />
</svg>
While I'm suggesting something like (in the simplest case):
<svg ...>
<filter id="myFilter"
requiredFeatures="http://www.w3.org/TR/SVG11/feature#Filter">
...
</filter>
<path filter="url(#MyFilter)" ... />
</svg>
Where Mozilla would simply not turn on that feature string until support
was better. It could selectively turn it on in particular
high-performance environments. This is the equivalent to your boolean
proposal, and is no more work for the author than your proposal.
In a more complex case, authors could do something like this:
<svg ...>
<switch>
<g requiredExtension="http://www.mozilla.org/fastFilter">
<filter id="myFilter">
...
</filter>
<path filter="url(#MyFilter)" ... />
</g>
<g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Filter">
<filter id="myFilter2">
...
</filter>
<path filter="url(#MyFilter2)" ... />
</g>
<g>
<linearGradient id="myGradient">
...
</linearGradient>
<path fill="url(#MyGradient)" ... />
</g>
</switch>
</svg>
This would use the built-in extensibility in SVG, and give the most
options to content creators, rather than only rendering the filter or
not based on a boolean value.
Mind you, I still think the boolean option would be better than nothing,
but this would require a minimum of special casing, and would build on
functionality already in Mozilla's SVG codebase. It's a more flexible,
longer-term solution, I think.
Regards-
-Doug
Ken Stacey
How about a filter-rendering property (a la color-rendering) ?
'filter-rendering'
Value: auto | optimizeSpeed | optimizeQuality | inherit
Initial: auto
Applies to: container elements, graphics elements
Inherited: yes
For FF3,
auto = optimizeSpeed = don't do the filter
optimizeQuality = do the filter (opt-in)
later, when filters are much faster,
auto could be anywhere between optimizeSpeed and optimizeQuality
optimizeSpeed could then mean using a low filterRes value (for example)
Ken
Doug Schepers
Ken Stacey wrote (on 1/3/08 2:21 AM):
Interesting idea, on the face of it. We would have to define what it
really means for each filter, perhaps... and I honestly don't know what
the desired effect would be in many cases. We are striving for interop,
but that can sometimes take a backseat to simple pragmatics of getting
anything to work at all.
In any case, it's worth further discussion. Could you please raise this
on www-svg?
Regards-
-Doug
rocal...@gmail.com
> rob...@ocallahan.org wrote (on 1/2/08 11:45 PM):
But this way, if the author just writes <filter>...</filter>, FF3
would apply the filter. So the default is really for filters to be
enabled, i.e., this is really opt-out.
Rob
Robert Longson
> Hi, Rob-
>
> rob...@ocallahan.org wrote (on 1/2/08 11:45 PM):
>
Firstly we plan to turn on the filter features soon. Tor has just
landed feImage support and I expect the final feDisplacement filter
will land very shortly. At that point we want to turn on the feature
strings.
Secondly some filters are fast and some are slow. feTile and feImage
are pretty speedy IMHO. Some such as feGaussianBlur are unarguably
slow. Switching based on feature strings will not really capture that.
Best regards
Robert.
rocal...@gmail.com
> Firstly we plan to turn on the filter features soon. Tor has just
> landed feImage support and I expect the final feDisplacement filter
> will land very shortly. At that point we want to turn on the feature
> strings.
>
> Secondly some filters are fast and some are slow. feTile and feImage
> are pretty speedy IMHO. Some such as feGaussianBlur are unarguably
> slow. Switching based on feature strings will not really capture that.
That argues for the mozEnableSlowFilters approach, I think. When
that's not set, we could enable feTile and feImage and disable the
rest. In that case we should only advertise the feature strings for
filters when mozEnableSlowFilters is set.
Rob
Doug Schepers
rob...@ocallahan.org wrote (on 1/3/08 4:36 AM):
>> While I'm suggesting something like (in the simplest case):
>>
>> <svg ...>
>> <filter id="myFilter"
>> requiredFeatures="http://www.w3.org/TR/SVG11/feature#Filter">
>> ...
>> </filter>
>>
>> <path filter="url(#MyFilter)" ... />
>>
>> </svg>
>>
>> Where Mozilla would simply not turn on that feature string until support
>> was better. It could selectively turn it on in particular
>> high-performance environments. This is the equivalent to your boolean
>> proposal, and is no more work for the author than your proposal.
>
> But this way, if the author just writes <filter>...</filter>, FF3
> would apply the filter. So the default is really for filters to be
> enabled, i.e., this is really opt-out.
Yes, sorry, my mistake. I was writing pretty late at night, and meant
to make an opt-in example. The syntax is not what I was emphasizing,
though that would have to be worked out. I'll send a better example
after I talk to the SVG WG.
Regards-
-Doug
Doug Schepers
rob...@ocallahan.org wrote (on 1/3/08 5:20 PM):
My concern with this is that, once a hack is in there, it's very hard to
get it back out.
Given that there is a demonstrable need for some optimization here, I
would actually favor a longer-term solution like Ken Stacey's
'filter-rendering' property (which *is* an opt-in solution.
One of the benefits to this is that if the author knew they were going
to be animating or scripting the filter-using content, they could always
opt for 'optimizeSpeed', regardless of how good the support for filters
is. For artistic static renderings, authors can use 'optimizeQuality',
even if it's dog-slow in FF.
Regards-
-Doug
rocal...@gmail.com
> My concern with this is that, once a hack is in there, it's very hard to
> get it back out.
What do you mean "get it back out"? In the long term, we won't support
mozEnableSlowFilters (all filters will always be enabled) and authors
will never need to use it.
> One of the benefits to this is that if the author knew they were going
> to be animating or scripting the filter-using content, they could always
> opt for 'optimizeSpeed', regardless of how good the support for filters
> is. For artistic static renderings, authors can use 'optimizeQuality',
> even if it's dog-slow in FF.
Ken's property would work, I guess. We could do that.
Rob
Ken Stacey
> Given that there is a demonstrable need for some optimization here, I
> would actually favor a longer-term solution like Ken Stacey's
> 'filter-rendering' property (which *is* an opt-in solution.
Without stretching the imagination too far, you could use the existing
'color-rendering' property as the opt-in hint for filters.
Ken
codedread
http://lists.w3.org/Archives/Public/www-svg/2008Jan/0068.html