Past, Present, and Future of Mozilla SVG

Timothy Rowley

IBM Corporation

John "Scooter" Morris

University of California, San Francisco

Jonathan Watt

University of Strathclyde

Alex Fritze

croczilla.com

Overview

• Why another SVG implementation?
• History of Mozilla SVG
• Current status
• Problems encountered
• Future
• How you can help

Why another SVG implementation?

• Plugin stagnation
• Standard part of browser
• Need to provide richer web
• Compound documents (XHTML, SVG, MathML, XUL)
• Combine with other Mozilla technologies (XBL, XTF)
• More possibilities for web applications
• More possibilities for user interface experimentation
• More possibilities for Mozilla as an application platform

Demo

• XForms Calculator skinned with SVG
• XForms and SVG form

MozMapEditor

• Cartography application
• Paul Rouget and Ren-Luc D'Hont
• XUL/JS/XBL/SVG/RDF application
• Will use WFS/WMS (Web Feature Service and Web Map Service) from http://www.opengeospatial.org/
• http://mozmapeditor.mozdev.org/

MozMapEditor (cont)

MozMapEditor (cont)

0th generation SVG

• 1999
  • Partial implementation of <path> without styling
  • Never checked in
• Early 2000
  • Netscape engineers
  • Non-antialiased polygons and polylines
  • No DOM, no CSS styling
  • Used Mozilla's existing plaform independent graphics layer for rendering

1st generation SVG

• Late 2000 - 2001
• Crocodile Clips
  • Educational software company
  • Interested in combining XUL, XBL, SVG, MathML
  • Need a drastically enhanced SVG implementation
  • Allocated a single engineer, Alex Fritze
• SVG shapes, antialiasing, alpha blending
• DOM, CSS Styling
• No text support
• Rendered via libart library

2nd generation SVG

• Needed text support
• Decision to allow platform specific graphics
  • SVG rendering layer
  • GDI+ for MS-Windows
  • libart for linux and other platforms
• Still primarily one engineer
• On-and-off branch development work
• Landed on the trunk early 2004

Current generation SVG

• New developers
  • Single engineer from IBM, Tim Rowley
  • Two volunteer code contributors (Jonathan Watt and Scooter Morris)
• Much feature work: markers, gradients, <use> elements, inner <svg> elements, <switch> elements, <clipPath>, viewboxes, <script> and <style> elements, event attributes, <image>, group opacity
• New rendering backend - cairo
  • LGPL/MPL license
  • Cross platform
  • Includes text APIs
  • Lots of linux community buy-in

Where we are

• SVG built and enabled in nightlies, Deer Park alpha 2, and the upcoming Firefox 1.5
• SVG 1.1 Full minus declarative animation, SVG fonts, textPath, filters, patterns

Where we are (cont)

• SVG can be used as the entire document or with <embed> or <object>
• SVG not available for <img> or CSS properties accepting images
• Disables any SVG plugin
• Performance
  • MS-Windows - pretty good
  • Linux - variable but generally ok
  • MacOS - poor
• Stricter implementation than some
  • Content needs to be served with image/svg+xml mimetype
  • Namespace must be specified
  • Do not use getters and setters
  • Use namespace aware DOM methods
  • http://www.jwatt.org/svg/authoring/

Where we might be

• New features
  • <textPath>
  • <filter> plus gaussian blur, component transfer, offset, and merge filters
  • <pattern>
• Code completed, under review
• Unclear if they will make Firefox 1.5

Why release now?

• Time for a graphics rich web has come
• Enough functionality to be useful
• Trying to gain critical mass so the project continues
• Increase SVG uptake

Problems encountered

• Implementation intergrated in Gecko core
• Non-trivial codebase to interface with
• SVG developers did not start out as Gecko experts; some mistakes were made

Problems encountered (cont)

• SVG specification doesn't mesh with others (CSS)
• SVG specification vague in areas
  • No errata published
  • W3C SVG working group frequently unresponsive
• Somewhat weak test suite provided by the working group
• Lack of manpower

Future

• Moving towards SVG 1.1 Full
• Rearchitecture to decrease code/memory footprint and increase performance
• Mozilla unified graphics architecture, enables full <foreignObject>
• SVG 1.2 implementation unlikely in current form

Future (cont)

How you can help

• Non-coders
  • Test your content on us
  • File bugs (bugzilla.mozilla.org), minimal testcase invaluable
• Coders
  • We'd love for you to get involved
  • Join irc://irc.mozilla.org/svg and talk with us
• Corporations
  • Allocate engineer time to work with us
  • Contract work

Thanks

• Thanks for your interest in Mozilla SVG
• Would love to talk
  • Grab me anytime this week
  • tor@acm.org
• More sources of information
  • http://www.mozilla.org/projects/svg/
  • http://weblogs.mozillazine.org/tor/
  • netscape.public.mozilla.svg newsgroup
  • irc://irc.mozilla.org/svg IRC channel