- From: Doug Schepers <schepers@w3.org>
- Date: Sat, 26 Jan 2008 00:10:09 -0500
- To: www-svg <www-svg@w3.org>
Hi, Folks-
We had a productive meeting, but didn't have quite the right group of
people to come to a resolution on this issue.
We did decide that having a richer set of featureStrings would give more
control to authors, but were undecided on whether to additionally
include a 'filter-rendering' attribute. There were a range of opinions,
some favoring it, others thinking it risked introducing
non-interoperability, still not seeing the need, and others who thought
it could be a temporary Mozilla-only solution.
It would be great to hold one more meeting, including representatives
from Inkscape (and any other authoring tools) and WebKit, as well as
Robert Callahan (who raised the issue originally) and Chris Lilley (who
has the most extensive SVG knowledge).
I propose another meeting, before it's too late to make an effective
solution for Mozilla. How about next Tuesday, January 29, at the same time?
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI
---------------------------
Attendees
Present
Doug, Andrew_Emmons, ed_, tor_, Andreas_Neumann, [IPcaller],
heycam, anthony, oliver, Robert Longson
<trackbot> Date: 24 January 2008
<oliver> Zakim: 1.408.974.5974 is oliver
<aneumann> Scribe: Andreas Neumann
<aneumann> ScribeNick: aneumann
Filter-rendering
<aemmons>
[9]http://lists.w3.org/Archives/Public/www-svg/2008Jan/0067.html
[9] http://lists.w3.org/Archives/Public/www-svg/2008Jan/0067.html
TR: people at Mozilla want to turn off filters on FF3 because they
are rather slow
OH: if you introduce a flag people will develop content for this
flag and if its later turned on content can be broken
DS: a lot of people who use SVG in filters don't do it for webapps
but for art, and they often will use an authoring tool
... so its not the same issue like with the IE8 flag
OH: we could also have a quality property on the whole document
... mobile devices can switch off filters if they can't do it
DS: switch and filter rendering are orthogonal
... filter-rendering is a hint for the UA
... the problem with filter-res might be that content is locked into
bad quality forever
<oliver> sorry phone just hung up
<oliver> will recall
<heycam> ScribeNick: heycam
<scribe> Scribe: Cameron
RL: the feature strings are too broad
DS: the more discrete the feature strings, the more authors can
tailor to UA issues
ED: i'm open to adding more feature strings to the filter module
... i think division of the filter modules in 1.1 basic was made
based on memory consumption
... of course memory consumption is something to think about when
you're targetting mobile devices
OH: filters + mobile devices isn't that nice anyway, too much
computation => battery usage
ED: it would be good to have more feature strings in any case. not
sure if that should be per primitive, or larger groups.
DS: i think per primitive
... any way we choose to group it, an implementation may have a
given set of issues
AE: erik are you proposing the feature strings instead of the filter
hint?
ED: not sure if this solves all the problems, there are different
use cases for it
AE: is there general consensus to add the filter-rendering hint?
OH: sounds like an icky hack to get around the problem of filters
not being efficient
... but i recognise that as a problem, don't know how to get around
it in a nice way
DS: also that nice way needs to include something that authors can
do/understand easily
... predictble behaviour, shouldn't have to know too much about it
to use it
AE: predictible behaviour is the biggest problem for me
ED: also worried about cases when authors force FF to start
rendering gaussian blue, using optimizeQuality e.g., but in other
UAs it'll make them go slower
DS: good point
... we could hope that by the time that it gets to be a problem,
firefox would've come out with a new version that can handle them
better
... thus making it so that authors don't have to do that
OH: how well does batik perform with filters?
CM: not very well, all implemented in java
AN: used mostly in static content though, where it's not so much of
a problem
OH: i know that webkit's filters, performance is bad when resizing
the window e.g., or the content underneath the filter changes
... for static content we have no issue, don't think that mozilla
does either
... are we only looking at the dynamic case then?
DS: i kinda think so. as filter implementations get better, this'll
let us say that "i know this filtered content will move around, so
i'm happy with optimizeSpeed"
... i don't think it's a hack (feature string / switching), it's a
good forward looking feature
AE: and we have other rendering hints
TR: are people using rendering hints in the way they were intended?
CM: i always use text-rendering to force text painting as glyphs :)
DS: i think it's fair for authors to use those things as hints to
UAs, no matter how the UA interprets them
... using it to stop antialiasing is fine, the author is going for a
certain effect
... it's just a hint, however the UA wants to implement it, towards
the spirit of the hint, go ahead and do it
OH: i'm kinda against the idea of hints in general
AE: the only issue, for optimizeSpeed to cause mozilla not to render
filters, it's not so good
RL: for a number of filters we could use filterRes to still render
something
TR: it would sortof give unpredictble results if we start doing that
RL: you could arbitrarily lower the resolution based on what filters
are there
TR: might be surprising to content developers in a bad way
DS: i agree
OH: that'd only happen after an author says "try to make this fast"
... so they should be aware that it's going to have a side effect
... the problem would be if they designed it as they wanted it, then
later version of firefox changes what it looks like
DS: i doubt they will complain if they get better quality
OH: doens't matter if it's better, but if it's different
... might change things in ways they don't want
DS: that's fair
... you've defined that where?
OH: no the spec defines that
AE: it doesn't seem like there's much consensus either way
ED: there's consensus for adding more feature strings in any case
DS: though that doesn't solve the issue that Robert O'Callahan
originally raised
... which is that you need to opt in to render filters
... two ways to solve that: screw around with filterRes, or a
mozilla specific property/attribute that says "yes mozilla i really
do want you to render these"
... or, a filter-rendering hint
... i see this as a long term issue, since nobody has a great
implementation of filters yet
... a lot of content out there depended on adobe's implementation
... if there is some difference in behaviour, they're going to see
it straight away
... on #svg, and on svg-dev, we frequently get questions like "we
looked at this in inkscape, then firefox, and it's completely
different"
... that's the kind of thing people will act towards
... most people aren't going to hand tweak filters to get a certain
effect
... if we can get some sort of agreement between authoring tools and
UAs, that would be best
... come up with some loose text about how to degrade different
filters, we could get some sort of interoperability
... does that address the concerns of those who don't like hints?
OH: i still think it should be possible to do it with a switch
statement
... because i think it's wrong to say do-or-do-not-do-this
... smallest machine i have is a dual core machine, and perfomance
there is acceptable
... so it'd be bad for mozilla to not render the filters, because my
machine can handle it
DS: this is something moz wants to do to protect users from bad
performance
OH: then it's up to them to look at a page to determine if they can
do render performantly
RL: are you suggesting that if i display an svg file on one machine,
and i display it on another, it shows a different thing?
OH: otoh, it also seems icky to make it not do that. what'll happen
in the end is that firefox will run on a mobile, and on a phone
don't render filters, on a desktop, render filters regardless of
this flag
... then you have different results on different machines anyway
DS: with filter-rendering the author has some control over that
... if firefox just looks at the page and evaluates it and then does
different things...
OH: this is what will happen anyway, when is rendering filters
acceptable for performance?
... firefox is targetting a mobile platform now, and i doubt they're
assuming the same performance characterstics as on desktops
... filters have to be much faster if you want them to work
acceptably on a mobile device
DS: i think the case could be made that mobile devices are a
slightly different case than quad-core vs single-core (fast) machine
... i think giving the author some control over whether they want
their filters rendered is preferable to having no control
OH: it's not hard to take out a browser by crafting a page to have
bad performance
DS: slightly different tack, has apple discussed this internally? or
just your opinion?
OH: i'm the only apple svg guy
... i'd like it if nicholas zimmerman could join
... but he doesn't have a company phone to use
DS: part of this same tick is, having had this conversation, how
does mozilla feel?
TR: depends who you speak to
... (someone) thinks filters should be on by default
... since it's fast enough for the original customer who we
implemented it for
OH: one minor implementation detail in filters is that we haven't
trimmed down the amount of recomputation with filters
... e.g. we recompute a whole filter even if it's not required
... which is likely to be a big issue for dynamic content
DS: ed, optimisations in the filter module?
... erik has done some work on working out good ways to have common
filter effects (drop shadow, blur, etc.)
OH: arguably you could do it with the css properties
DS: yeah
RL: i would just go for filters
... but i think Robert O'Callahan is the driver for putting in some
kind of restriction
TR: i don't know if that's his opinion, or other people in mozilla
pushing him for that
DS: i'm not sure we have the right people on the call to resolve
this in a good manner
... don't have chris, nicholas zimmerman, inkscape, roc
... i will say that roc wanted a switch to opt in to do it
TR: it seems at this point, unless we manage to change his mind,
that filters will be turned off in firefox3
DS: but the door is still open for opting in
TR: yes, leaving the filter code in there, and opting in in some way
DS: I propose we just publish this part of the log to www-svg and
ask for a quick e-mail resolution to this
... unless you guys really want a resolution right now
AG: question for tim, how'd you feel about olaf's suggestion for a
namespace'd attribute?
TR: i was thinking of making the filter-rendering as a presentation
attribute, maybe -moz-filter-rendering
... apparently that isn't acceptable to some people
... maybe namespaced, have to look into it a bit more
DS: I guess the open question is if you're going a moz specific
thing, either do it css alone (with the vendor prefix extension
mechanism), or namespaced attribute, since that's the mechanism for
svg
AG: i thought it might've been another (namespaced attr)
DS: long term people will want to say "i expect this content to be
dynamic, so i want to optimise for speed"
... or vice versa
... taking it to www-svg,svg-dev might get us some insight into what
developers want to do with it
OH: might be worth considering having an internal conversation with
the inkscape guys, roc, nicholas zimmerman, to get some idea on
whether we can come to consensus
DS: i'm happy with that
... next week i can't be there though
AE: next tuesday's telcon?
DS: tor when's your deadline?
TR: features discussed so far have been simple enough to implement
by the deadline
DS: you could just implement one way, and if we don't agree, just
rip it out
TR: 30th jan is the next beta deadline
AG: so we have a week
DS: assume we can get people available next tuesday, and i'll try to
break away from my meetings to join in
<aemmons>
[10]http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JanMar/0124.h
tml
[10]
http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JanMar/0124.html
Received on Saturday, 26 January 2008 05:10:16 UTC