W3C home > Mailing lists > Public > www-svg@w3.org > January 2008

Minutes From Filter Meeting, Next Steps

From: Doug Schepers <schepers@w3.org>
Date: Sat, 26 Jan 2008 00:10:09 -0500
Message-ID: <479AC0B1.7000402@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT