Saturday, 9 February 2008

The Best Of Intentions

I've been working on SVG filters, trying to get the World Of Ecmascript SVG version to not suck when you load it in Firefox 3. There are some interesting lessons in how not to write a spec for the Web.

Basically, the SVG Working Group tried to "help" implementors by having the filter markup describe the bounds of the region that the filter will operate on (the filter effects region and the filter primitive subregions). This puts a burden on authors and their tools, but it should help us browser developers, right? Unfortunately no. What has happened is that some tools generate bad markup; in particular Omnigraffle has produced markup that basically says the shadow of every object in W.O.E. is the size of the viewport! Our naive filter implementation follows that "advice" and applies filter effects to enormous filter buffers, which is of course incredibly slow and wasteful.

Dealing with bad markup is what browsers do, and in this case it's not hard in principle. We just have to ignore the markup hints and compute reasonable bounding boxes for the temporary surfaces required by each filter effect. I have a patch that does just that, and it turns W.O.E. from "hangs the browser" to "almost snappy". The problem is that the filter attributes specifying the filter effects region are now an unnecessary burden on authors. In fact, it's worse than that; the spec says that the renderer must clip rendering to the filter effects region and the filter primitive subregions, so we have to go ahead and compute them from the markup (not trivial) just so we can clip filter effects as per spec ... clipping the author probably doesn't want anyway.

This is a classic case where well-intentioned spec authors have made life unnecessarily difficult for everyone. Specifying "hints for the implementation" can be useful --- e.g. CSS 'text-rendering' which we support in FF3 --- but you have to be sure that if the author (or her tools) gives the wrong hint, the results are not disastrous. You also have to be sure that implementations are allowed to completely ignore the hints if taking advantage of the hints would be more trouble than it's worth.

I should mention that although this is an example of where the SVG spec kinda sucks, it's also an example of the utility of SVG that we've able to render vector graphics exported by applications like Omnigraffle.



11 comments:

  1. Why does Omnigraffle get a pass on this? It sounds like they were lazy and took a shortcut, and now Mozilla, gets cruftier in order to deal with it.
    Wouldn't an alternative have been to let them know that they are not doing things correctly and warn them that their files are going to suck in Firefox? I'm sure that would more than enough impetus to get them to fix their SVG generator fairly promptly.
    Being flexible with interpreting dodgy input is
    of course the best approach usually, but I can't help but think that this is kind of taking it a step too far...

    ReplyDelete
  2. James Napolitano9 February 2008 13:09

    It sounds like every web or browser developer who touches SVG ends up hating parts of it. Would it make any sense for the WHATWG to rewrite SVG, or make a new "WebSVG" dialect, that would be more sane, kind of like what they did with HTML5? Any realistic chance of that happening? SVG is much younger than HTML and not nearly as widely adopted on the web, so maybe there would still be time to fix the spec.

    ReplyDelete
  3. Just in case anyone is wondering: he's not kidding about the "hang your browser" part. I just forcibly closed Firefox after being curious.

    ReplyDelete
  4. I'm still using FF 2, so maybe this issue is already addressed on FF 3, but I thought I'd mention it anyway.
    FF has the useful behavior that if an image is larger than the window, it gets resized, the cursor turns into a + sign, and clicking on the image allows going back to full resolution (and back again with another click).
    It would be nice if SVG-based images had this same property. I had a look at the W.O.E. svg on FF2 and it is much larger than my screen.
    Having SVG-generated images behave like all the other image formats would be a nice desuckification of SVG support. A web author could choose to export an svg or a precomputed image of the svg without it grossly changing behavior.

    ReplyDelete
  5. Robert O'Callahan9 February 2008 21:42

    Paul: someone should tell Omnigraffle as well, but you really can't stop poorly-written documents from proliferating. (Well, the spec should require browsers to reject genuinely *invalid* documents, which will stop those.)

    ReplyDelete
  6. SVG's kind of over-the-top crazy in a bad way. I agree with James that someone has to take charge to make a sane version.

    ReplyDelete
  7. Hi Robert
    I am intending to submit an SVG bug to Bugzilla, but since this is new territory to me could you advice how I am supposed to describe it. It is shown at http://keryx.se/dev/svg/geckobug-08-01/

    ReplyDelete
  8. I've never understood this: Why don't we just use PDF as a vector graphics format for the web? At this point, Mac OS X and Linux have half-decent PDF libraries, at it would be possible to ship one for Windows. PDF is widely supported by vector graphics tools, and is relatively well documented. Would this be better than SVG? Worse?

    ReplyDelete
  9. Robert O'Callahan11 February 2008 06:25

    Lars: just file the bug, do your best to describe it and CC roc@ocallahan.org. We can have a conversation in the bug if your description isn't clear enough.
    Evan: a few major issues: PDF isn't XML-based, has no CSS integration, and has no DOM API.

    ReplyDelete
  10. Robert O'Callahan11 February 2008 06:28

    Lars: the problem with your page is that you're using very small pixel font sizes, and strange things happen when you ask the OS for a 0.65px font. Try scaling everything up so you're using 65px fonts, then it should look fine.

    ReplyDelete
  11. If the problem is bad content creators, surely the easiest solution is to tell them they're broken, and be done with it. While we still can.
    Compare the problem of CO2 reduction now and the CFC's in the 80's. We were able to stamp out CFC's because there were still only a few factories making them. This is not possible now with CO2, we would've had to start in the 1880's..
    This looks like the same problem we all tried to fix with our css hacks and browsersniffing when IE6 got big, and when wysiwig editors started to become widespread, making buggy code. We didn't have enough clout to make a stand back then, but we do now.
    Say no to buggy software!

    ReplyDelete

Note: only a member of this blog may post a comment.