2D Drawing/Vector Graphics

From RuntimeWiki

Jump to: navigation, search

Contents

Title

Support for 2D Drawing/Vector Graphics

Detailed write-up

Description

All major browsers have some support for vector graphics. At this time all major browsers have committed to some level of SVG support except for Internet Explorer. But the implementations are lacking in consistency and completeness:

  • The Opera web browser (since 8.0) has support for the SVG 1.1 Tiny specification while Opera 9 includes SVG 1.1 Basic support and large parts of SVG 1.1 Full. Since 9.5 alpha 1 Opera has partial SVG Tiny 1.2 support.
  • Browsers based on the Gecko layout engine version 1.8 (such as Firefox, Netscape, Camino, SeaMonkey and Epiphany), all have incomplete support for the SVG 1.1 Full specification. The Mozilla site has an overview of the modules which are supported in Firefox 1.5[14] and an overview of the modules which are in progress in the development version of Firefox.[15] Gecko 1.9 will be included in the upcoming Firefox 3.0 and will add support for more of the SVG specification (including some filters).[16]
  • KDE's Konqueror has a SVG plugin called KSVG. KSVG2 is slated to be rolled into KDE 4 core which could make it native rendering for Konqueror some time in the future. KDE 4 will also feature system-wide support and use of SVG for graphics. Elsewhere in KDE the format is finding greater use, and from version 3.4 onwards SVG wallpapers are supported.
  • Apple's Safari browser ported KSVG2 into WebCore, initiating work on incorporating native support of SVG into Safari.[17] The version of Safari included with Mac OS X v10.5 and Mac OS X v10.4.11 includes SVG support; which is not perfect, but has seen rapid improvement. In fact, the latest WebKit builds are far along in terms of implementing everything in SVG 1.1 Full.
  • Internet Explorer has support for VML, instead of SVG.

The same browsers that support SVG also support the HTML5 <canvas> tag. The <canvas> tag provides a rich set of 2D drawing capabilities, but only supports vectors and images, without support for text (which SVG provides). Also, <canvas> is only for drawing. There are no features for interactivity, such as establishing event handlers for mouseover or click on a particular graphical object; no support for a hierarchical grouping of objects within a graphic; no DOM support; and no support for declarative animation. (If this characterization of <canvas> is inaccurate, someone please fix.)

Why Is This Important?

Web designers demand vendor-neutral, cross-platform interoperability. SVG brings the advantages of XML to the world of vector graphics. It enables the textual content of graphics - from logos to diagrams - to be searched, indexed, and displayed in multiple languages. This is a significant benefit for both accessibility and internationalization.

JavaScript developers have undertaken the task of helping overcoming the inconsistency of implementations among different browsers. “dojox.gfx” is an example of providing a consistent JavaScript API to enable developers creating vector graphics in a cross-browser context. However, such efforts can certainly benefit from continued progress from various browsers.

Proposed workarounds

Some Ajax toolkits and commercial products have implemented heroic JavaScript that takes a generic 2D graphics model and maps it to SVG on Firefox, Safari and Opera, and then VML on IE. (Sometimes also Canvas and Silverlight.) One popular library for this is:

dojo.gfx does a fine job of rendering a fairly rich set of static 2D graphics drawing APIs (compositing vectors, text and images, with transformations), and can achieve event-based interactive graphics and animation effects by leveraging other features in the Dojo toolkit. However, because some of the heavy lifting is done in JavaScript, there are scalability issues, and the (abandoned) VML implementation on IE is slow and less reliable with each new release of IE. To use dojo.gfx effectively, you need to go up Dojo learning curves.

Another library that provides a unified server-side API to vector graphics in the browser (on top of SVG/VML/Canvas) is Wt:

Background material that request this feature

Discussion

Jon Ferraiolo's comments

The obvious request is for IE to FINALLY IMPLEMENT SVG in alignment with the other browsers. SVG has been a standard since 2001 and is fairly ubiquitous on mobile devices due to OMA, 3GPP and JCP standards, and is used for various commercial mobile applications, with a lot of SVG used in Mobile TV applications. Microsoft obviously has the know-how to implement this functionality, given that Silverlight supports roughly the same feature set.

<canvas> support would be better than nothing, but SVG support allows for interactive graphics, versus just the ability to draw graphics.

The question then becomes which flavor of SVG do we want. The W3C supplies four profiles:

  • SVG Full 1.1 - Generally matches what shipped in Adobe SVG Viewer back in 2001. Opera generally supports this level (graphics, scripting and animation). Firefox supports most of the static graphics and scripting features from SVG Full 1.1, but not the animation features. Safari3 roughly matches Firefox, but Surfing Safari says animation (to pass Acid3) is coming soon.
  • SVG Basic 1.1 - Simpler graphics feature set, only requires a subset of filter effects, and simpler DOM. Bottom-line: drops some of the features from Full that aren't used much. This profile was implemented at one time by Bitflash, possibly is still alive, otherwise no browsers have targeted this level.
  • SVG Tiny 1.1 - Full 2D graphics, except no clipping or masking. Includes declarative animation, but no JavaScript. (That was added with Tiny 1.2.) Strong industry adoption on mobile devices for SVG Tiny (sometimes 1.1, sometimes 1.2), where SVG ships on hundreds of millions of phones today. SVG Tiny is a mobile industry requirement that is specified as a requirement by various standards from OMA, 3GPP/MPEG (MMS/DIMS and LaSER), and JCP/J2ME (JSR226, 287, 290).
  • SVG Tiny 1.2 - Adds various features to Tiny 1.1, including scripting and multimedia (i.e., an <audio> and a <video> element). Tiny 1.2 is sometimes used for device-resident mobile video applications, where typically SVG is used for the user interface around a video. Vendors that support SVG Tiny 1.2 include mobile suppliers Bitstream, Ikivo, Opera and Streamezzo.

A few years ago, I would have recommended that browsers support SVG Basic, but given how far Mozilla, Safari and Opera are along on implementing SVG Full, my recommendation is to go all the way and deliver SVG Full 1.1 support. Regarding the features from Tiny 1.2, I would recommend following Opera's lead and setting that as a future target, but the most important feature from Tiny 1.2 is supporting the ability to integrate audio and video with the rest of the composition.

Additional to what features in SVG to support, the other question is the degree to which the SVG support needs to integrate with the HTML engine. The Acid3 tests (and as a result, Safari/WebKit, and one would assume Opera) are going for full integration, where SVG can be interspersed inline within the HTML and an SVG graphic can be used wherever a raster image can be used.

One more thing: large segments of the community will not accept a proprietary plugin approach that supports a proprietary graphics language. Two reasons: (1) large segments of the industry buy into the whole "Open Web" schtick, (2) various competitive forces will prevent proprietary languages from being universally available, such as where one vendor will not allow an archrival's proprietary format to ship with any platform that they control. For example, it seems unlikely that Windows Mobile would ship with Adobe AIR, or that the iPhone would ship with Silverlight (and as Steve says, Flash is too slow!).

Brad Neuberg's comments

I agree with Joe; just get browsers to implement SVG Full. I'm not a huge fan of SVG, but it exists and is slowly percolating into place. Its good enough. Also, I think browsers should just implement the canvas tag as well. Its much easier to work with then SVG, especially programmatically, and is turning into a defacto standard. SVG + canvas are good options to have in all browsers. Something important to mention is that browsers should also be able to do good things with text inside of SVG or canvas. I don't think there are any proposals around better fonting on the web, but not being able to do interesting things with fonts inside of SVG or canvas is a major limitation versus Silverlight or Flash. Another 'nice-to-have' would be to able to 'save' the state of an SVG or canvas graphic into a file that you can post. This is useful for annotation tools, web-based drawing tools, etc. that need to save their state. You can see some of the work Gears has been doing around these things: http://almaer.com/blog/gears-future-apis-image-manipulation-api You can create images, turn them into blobs, and then show them on the screen or post them to a server. Disclosure: I work with Google and the Gears team.

Jon Ferraiolo's comments (v2)

(Why does everyone thing I'm Joe and not Jon?) Regarding SVG's shortcoming, the browser vendors need to advance both SVG and Canvas incrementally. SVG was designed back in 1998 and is showing its age. HTML is advancing with the HTML5 effort, and the same sort of a thing needs should happen with SVG. It is great to see all of the innovation with Canvas in recent years. Let's merge the efforts such that there is an underlying graphics capability that can be manipulated via markup and the DOM using SVG or procedurally using Canvas APIs. Probably can't merge every feature, but opportunistic merge makes sense. Also, there is a lot of SVG support in products out there, so backwards compatibility is important, but not everything in SVG should be sacred. There are a lot of stupid things in the SVG language, such as (just to name a couple) additive clip paths and chaining of gradients and filters, that are not used by anyone or used by a very small number. In particular, not every feature in SMIL Animation should be considered sacred. SMIL is good because it is a W3C standard, but has some significant shortcomings for web multimedia. Filters need to be reworked in a major way. Graphics performance is key, so focus on the ability to leverage OpenGL for performance.

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:


Phase II Voting

More about this later.

Personal tools