The author seems to have missed, apart from an initial mention, VML out completely. VML was Microsoft's SVG alternative in IE 5 through 8, not Sliverlight. Sliverlight was a Flash alternative.
VML, although badly documented, can/could do much of what SVG can do, in a few cases it does it better. It was also pretty complete with IE 6 in 2001. SVG had the first very basic version in Firefox 1.5 at the end of 2005, and needed Firefox 3.0 in 2008 before you could say it was reasonably complete. MS thought they had a head-start and could win the vector battle.
The key thing, as well, with VML is that it was built into IE natively. Getting Adobe SVG or Sliverlight added onto IE into large corporate environments was near on impossible. We, fortunately, decided we didn't trust Adobe prior to them killing the IE SVG plugin and were running fully on VML at that point.
The last 10 years of my working life have been based around SVG and VML, my co-founder and I would tell you a similar story. Especially, regarding word-wrap in SVG, it's our top pain point as well. It forced us to use HTML as foreign objects in SVG to get word wrap. Of course, IE never supported FOs, Edge has only just added it.
Silverlight was probably the last major Microsoft attempt at platform lock-in, but it was too late; arguably it was killed by Apple's platform lock-in barrier on iOS just as much as Flash was.
The huge pain point in SVG is fonts. Native SVG fonts died. Trying to do exact pixel-perfect layout in SVG for text is now very difficult. See trying to measure the width of a string in a given font.
I think the more interesting aspect is that Adobe hires so many developers with vector graphics experience that it is harder to find them in the SF Bay Area (from the talent pool who is interested/willing to work at a startup). Obviously, this is conjecture.
But definitely a huge thanks to Dmitry for his work and for sharing it.
Years later I was interviewing and my interviewer asked me a lot of questions about one example in particular. It turns out he had run across an example and it was exactly what they wanted for their project, but they didn't understand the math. He had tried to find me with no luck, going so far as to call Adobe and find my coordinator who refused to give out my name.
I opened the sample for him (it was still up), clicked on View Source and pointed to the first line that said "Author: [My fairly unique name]". His response was "DAMN IT! It was that easy?!?!?!"
Liquid Motion seemed like it could do some damage as DHTML was huge from IE 3/4 and it had the developers on their side because Netscape was wallowing and sucked (document.layers), but they just dropped it. They also did that with tablets and phones so Microsoft usually needs a successful example they can innovate on it seems, otherwise they fumble a bit.
Then Microsoft bought Dimension-X (acquihire) and tubed the product, leaving me an orphan. Liquid Motion greatly boosted the mindshare for Java. An OpenGL code base written in Java validated both technologies. So of course it had to die.
For Sun's part, they went the full quixotic with Java 3D, for years refusing to acknowledge anyone would want to use just OpenGL as is. But for its time, Java 3D was the J2EE of scene graph libraries [ducks].
Source: I helped former Liquid Motion employee "Alligator Descartes" design and implement the first public Java OpenGL bindings called "Magician", which was copied by JOGL and others.
A frequently asked question is: Why doesn't Avalon just use SVG? On the face of it, it seems strange to invent a new way of representing vector graphics in markup when a standard already exists. However, the principal advantage of these shape classes is that they have been designed to integrate into the Avalon programming model. The vector drawing elements derive from the same FrameworkElement base class as all other XAML elements, and follow the same naming conventions. SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library. Furthermore, SVG elements were not designed to fit into the Avalon object model. By not using SVG, Avalon ensures that vector graphics can be mixed in with any other kind of markup in your XAML, and can take advantage of all of the same layout facilities. (Note that in the version of the Longhorn SDK documentation released at the 2003 PDC, the XAML elements used for vector drawing are sometimes referred to collectively as WVG (Windows Vector Graphics). However, Microsoft is no longer using this name, because it implies, incorrectly, that these elements are somehow distinct from all of the other elements supported by Avalon.)
I had some visual analytics tools that ran "canvas" on IE6 in 2008 thanks to VML. Never did pure VML but it was a nice crutch to have if you wanted to get very experimental and very cross-browser.
Also you can run that library on the server with node.
As an example, see this unfinished asteroids SVG I wrote in '09 (before <canvas> was generally available):
(seriously, it's not actually a finished game - damage is disabled, there's no levels/etc, but you can move with the arrows, shoot with space, (useless) shield on x)
The problem was the (slow) reflow every time you changed the DOM. I tried a few ideas to batch changes or pre-allocating elements, but browsers just couldn't run it consistently smooth enough at the time. It's somewhat better now - maybe I should actually finish it...
On the positive side, ReactJS plays great with SVG. I'm working on some basic line charts that I want ReactJS-managed so I can render them server-side too. My line chart isn't done but I tried the server-side rendering and it's working great.
A great way to "snatch defeat from the jaws of victory," re scalable graphics.
Works in theory. In practice, it does not. That is what I found but again, I'd be happy to be wrong.
I think it often comes down to what's the easiest asset workflow that gets us a good result. From that perspective, 1x raster + 2x raster is less work than 1x raster + SVG
Truetype fonts are an example of a vector format that can still look sharp at arbitrary resolutions because they can include hinting programs that align the control points to pixel boundaries. This is why fonts tend to look sharper on Windows and Linux than MacOS X. Linux and Windows default to strong hinting, and MacOS X uses only slight hinting, preferring accurate shapes to sharpness.
I know you already know these things, but for the sake of discussion (or other people).
Linux allows you configure hinting. It's true that by default (depending on how you define default) you get no hinting, but no reasonable distribution that I know of has shipped with that default for the past 7 years. Quite the opposite in my experience. Linux fonts (thankfully) look more like OS X fonts than Windows fonts.
Unfortunately, this configuration usually happens in some Gnome/Unity/XFCE/KDE configuration format, so if you want to use a better window manager with no DE, you sometimes have to recreate this from scratch, although, as someone who obsesses over font rendering and doesn't like the DEs, this is easier now than in 2000.
And then you have Google Chrome who just ships with its own font rendering. Gah.
For a quick glance, take a look at this nasty ultra-dense rendering in FF/Chrome and compare it to IE: http://projects.voanews.com/ebola-tracker/ (uses raphaeljs so renders in SVG or VML, whichever is supported.)
It doesn't -- it's the same as a bitmap in the default resolution rendered. And it gets even better when you zoom-in on those 'low resolutions'.
This is what we do for the cards at http://greenfelt.net. We lose a lot of detail in the face cards when we render them directly to the correct size as SVGs, especially at small sizes. There's a price to pay, of course, and it's a slightly more blurry look.
Another tangentially related but interesting fact is that every card set we have rendered as a pngcrushed png (except for the absolute largest size) is a smaller than the SVG source code.
Considering SVG is XML and PNG is binary, I am not totally surprised. Does that still hold after gzip compression?
svg in iframe + srcdoc + sandbox gives you sortof-inline svg with separate security contexts.
only plain inlined svg should be a security risk.
Design once in Illustrator (export SVGs) -> Code once -> Run everywhere
It is definitely a partial subset and creating VectorDrawables from any sort of design program is a giant PITA. The best strategy is making an SVG and then going through the XML by hand and turning it into a drawable (ugly I know).
Clearly this is the future direction of Android, but as of today it is still only half implemented.
As for why we didn't have SVG from day 1 on Android, I'm going to guess that is all a performance optimization. It's hard to overstate just how slow & weak early smart phones (iPhone & Android) were relative to today. We've expanded the scope of the apps to fill the available resources (as software engineers always do), but now there is enough head room to handle it all.
Even better, they get converted to PNG at build time for older SDK targets that can't display SVG.
Your move Apple.
A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.
The library takes half a megabyte under archlinux:
It also requires a 1.2 megabyte css parsing library: https://www.archlinux.org/packages/extra/x86_64/libcroco/
And of course also a 8.8 MB xml parsing library: https://www.archlinux.org/packages/extra/x86_64/libxml2/
Now compare this with libpng:
half a megabyte and the only real dependency is zlib, which is also in the dependency tree of librsvg
Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.
I don't bother using jpg's, png's of gifs anymore. Whenever I can, I use vector designs exported to SVGs (backgrounds, custom iconfonts, logos, shapes, animations, etc...)
Here's a Press Release about it:
2. WebGL and even Canvas are significantly more performant. I realize that's comparing apples and oranges... Still, if I had a choice for any data visualization project today I'd use WebGL rendering, or ThreeJS etc.
It did seem rather unfair of the article to bash Microsoft/IE so much over SVG support, when actually today the performance and sometimes rendering quality in IE is dramatically better than the likes of Chrome and Firefox.
But in any case, you're right, performance is a significant real world concern if you're using SVG for anything beyond very simple diagrams or line art.
It might not be a perfect standard, but it's a glorious feature set the web needs.
Right click on google.com and do a view source.