
Animated SVG vs. GIF - robin_reala
http://sarasoueidan.com/blog/svg-vs-gif/
======
adamredwoods
Ideally animated SVG should be self-contained as an image format, and easily
injected into an existing page, but it's not. It needs dependencies to
animate, either CSS (which is a bit fiddly) or a javascript lib.

GIF is easily injectable, easy to update, which allows a nice, quick iterative
update cycle. It's also compatible across the board and pretty future-proof at
the moment.

SVG animations could work better by containing the code within the SVG file
itself. Not sure how compatible this would be, but something to look into.
[http://stackoverflow.com/questions/5378559/including-
javascr...](http://stackoverflow.com/questions/5378559/including-javascript-
in-svg)

~~~
afloatboat
Well, SMIL does exactly that but has lost traction and has been deprecated in
favor of CSS and JS animations. Support has actually been removed in Chrome or
will be removed in the near future.

~~~
cpach
I remember reading about SMIL back in 1999 or so. Any idea why it never
catched on?

~~~
skavish
main reason is very hard to do something manually and at the same time
virtually no authoring tools

everything else is just a consequence of those

------
nv-vn
I'm quite sad the the animated PNG format never caught on. Not only does it
have a technical edge over GIF (full alpha channel transparency, more color
channels, etc.) but it also tends to have better compression/smaller file
sizes. I think that if Google had implemented support for it in Chrome it
likely would have caught on.

~~~
davej
I agree. It would be nice to see a format like Sublime Text's pseudo animated
GIFs [0] take off. It's not perfect because it requires JS + PNG + JSON and
currently the python build scripts only work well on linux. If other tools
started providing export functionality to this format then it could get more
interesting. Historically, iterating on these ideas on the client has been a
good way to get standards implemented in browsers.

[0]
[http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.h...](http://www.sublimetext.com/~jps/animated_gifs_the_hard_way.html)

~~~
Leszek
That's a very interesting approach, the packing in particular is much better
than the usual transparency hack used for GIF animation compression. Using
overlayed divs for faux-blitting where canvas is unavailable is also cool,
though perhaps somewhat fragile.

------
muglug
Tooling is the big issue here – there are lots of ways to create animated
gifs, but very few to create svg animations.

All the examples deal with programatically-created animations, but there's
definitely a market for a tool to create Homestar Runner-type animations using
SVG.

~~~
hemdawgz
That market was Flash, which has an absolutely huge content base of now-aging
vector animations and games. I'm still not sure what the general rationale was
for flash support becoming uncool, technical or otherwise.

edit: I suppose it was widely used for web applications or even entire
websites, which is now an obviously inappropriate use case, but I've still yet
to see any new web technology properly replace it for polished vector-rendered
animations or games.

~~~
josteink
> I'm still not sure what the general rationale was for flash support becoming
> uncool, technical or otherwise.

Flash became a pseudo web-standard, and a closed one so. This meant Flash-
support could only be implemented on devices and platforms Adobe decided to
support.

And Adobe's history when it comes to fixing bugs, problems and providing
adequate support for anything but their #1 platform (Windows) was appalling.

When Apple launched the iPhone, they decided that they didn't want their
platform dependant on other's people code and limited to whatever effort Adobe
would bother to put in.

At the time it was a ballsy move, as flash was surely king. In retrospect, I
think it worked out (mostly) fine and I'm glad they were willing to foot the
risk.

I say "mostly", because with Flash going away, people have been asking for the
open HTML-standard to include closed elements which they earlier would
typically do in Flash: DRM and friends.

The result is that the open HTML standard is no longer open and that open-
source software can no longer fully implement a standards-comliant web-
browser, meaning you can only get "working" browsers from the big guys like
Apple, Google and Microsoft.

That's a terrible loss for the web and for the future.

~~~
silvestrov
Adobe never provided a usable non-dog-slow version of Flash for iPhone.

So Apple only had the choice between no Flash and a really bad version. Flash
ran really slow on OSX compared to Windows, so it was unrealistic to expect
Adobe to suddenly provide a good implementation of Flash for the iPhone. Adobe
painted them into the corner by not properly supporting small platforms.

------
valarauca1
SVG is a pretty solid image format.

The issue is... It supports the execution of javascript as part of its
standard. So suddenly your image file, becomes an entire webpage. Not to
mention its pretty trivial todo some write malicious things with SVGs.

------
notthetup
One thing to keep note of is that SMIL is being deprecated by Chrome.

[https://groups.google.com/a/chromium.org/forum/#!topic/blink...](https://groups.google.com/a/chromium.org/forum/#!topic/blink-
dev/5o0yiO440LM)

~~~
jongalloway2
SMIL is unnecessary, as explained in the article - use CSS or JavaScript to
animate.

~~~
derefr
Having a self-contained document-type is the cornerstone of sharing/remix
culture. If you want people to be able to post your neat animated-SVG
infographic to Facebook or Tumblr or Imgur or wherever—or to make some
derivative of it with a meme plastered on top (and you probably do)—it needs
to be able to be right-click-downloaded as a single file, edited as a single
file, and then re-uploaded as a single file.

~~~
leni536
CSS and Javascript can be embedded.

------
mkj
Pity the "performance" bit didn't mention CPU time - slow cheap phones deal a
lot better with animated GIF than SVG.

~~~
1ris
So do regular computers.

~~~
kalleboo
Know of any stats to back that up?

~~~
1ris
It's just plain obvious that decoding a gif into a frame buffer is simpler
than merely parsing the xml. Not to speak of rendering the vectors and
animating them.

For rending each pixel in the frame buffers has to be set at last once, for
both. In the case of Gif a simple lookup is performed for each pixel. In the
case of SVG quite complex algorithms are required. I also suspect that the gif
decoding is much cache friendlier.

My statistic: The SVG animation stutters, the gif sutters less.

~~~
kalleboo
It's not obvious to me, since my historical experience has been that a lot of
browsers have had very poor performance with GIFs as soon as you have a bunch
on a page, or you do something special like add some transparency or layering.
Meanwhile, for CSS animations Safari set the bar high with GPU acceleration in
their first implementation.

I don't know much about SVG so it would be interesting to learn how the real
situation is there rather than some hunch.

------
billrobertson42
I have an application that generates html export for display in a browser. One
of the requirements of the application is that it needs to be able to run on
computers with no external network connection.

I recently had to add some auto-scrolling capability to the display to support
projector display. Users need to be able to copy the html file to usb devices,
and so it wasn't really in the cards to use external images for buttons, so I
simply embedded svg images for the play and stop buttons.

It worked well.

~~~
daurnimator
You could have used a data: URI

~~~
billrobertson42
Can you give an example, or a link to an example?

~~~
daurnimator

      - https://css-tricks.com/data-uris/
      - http://caniuse.com/#feat=datauri
      - https://www.ietf.org/rfc/rfc2397.txt

------
1ris
It's kind of ironic that the SVG animations stutter a way more than the gifs
on my i5 while the text advertises svg as smoother.

Reminds me of a text about typesetting. The author was surprised that
newepaper publishers switched from PostScript to Bitmaps (so from Vector to
pixel graphics). But Bitmaps are just a way simpler to handle and with bitmaps
the worstcase is the average case.

~~~
witty_username
Which browser? I'm running an AMD A4 and the SVGs are much smoother.

~~~
1ris
A current firefox on a somewhat dated X220 Thinkpad with a i5 core.

------
legulere
The two big problems with SVG are:

It's unsafe because it can contain javascript. You can't just let users upload
SVG files, you need to strip them. As far as I know there is no image hoster
that supports SVGs and I know of no website that contains user-uploaded
pictures that allows SVGs.

Then there's the issue that SVG is an extremely complex format. It's not a
format that's optimized for rendering like jpg, png, gif, but one optimized
for working on it like psd, xcf, raw. No browser supports all of SVG. You can
animate SVGs without javascript with the <animate> tag, but Firefox doesn't
support it. There's some weird features basically nobody supports, like
defining fonts inside of SVG. There are many features that are made for
editing SVGs by hand, but if you ever opened a SVG generated by a GUI program
like Inkscape you know that nobody would ever want to do that. The path format
on the other hand is optimized for space and isn't really human readable.

~~~
espadrine
SVG is in some way an advanced, editable version of PostScript, PDF's
ancestor.

Any SVG inside of an <img> tag is as safe as any image format. The JS code
won't run, any external resources linked to from inside the SVG won't be
loaded, the :visited CSS style is disabled[1]…

For added security, you can even send an HTTP tag called Content-Security-
Policy: default-src 'none'; img-src data:; style-src 'unsafe-inline' gives
good results. That's what GitHub uses, by the way[2].

> _It 's not a format that's optimized for rendering like jpg_

You could argue the same of jpg in a comparison between jpg and bmp.

You can animate SVGs even within an <img> tag with SMIL or CSS.

Sure, there are a lot of features, and you could argue that it makes SVG
complex; but the SVG specification[3] is not that much bigger than the PNG
specification[4], if at all. It is irrelevant anyway when edited through a
program, as PNGs usually are.

[1]: [https://developer.mozilla.org/en-
US/docs/Web/SVG/SVG_as_an_I...](https://developer.mozilla.org/en-
US/docs/Web/SVG/SVG_as_an_Image)

[2]:
[https://github.com/atmos/camo/blob/master/server.coffee#L43](https://github.com/atmos/camo/blob/master/server.coffee#L43)

[3]: [http://www.w3.org/TR/SVG11/](http://www.w3.org/TR/SVG11/)

[4]: [http://www.w3.org/TR/PNG/](http://www.w3.org/TR/PNG/)

~~~
legulere
If you look at the pdf versions you will see that the png specification is
shorter by a factor of 10.

SVG: 826 pages [http://www.w3.org/TR/SVG/REC-
SVG11-20110816.pdf](http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf)

PNG: 81 pages [http://www.w3.org/TR/REC-png.pdf](http://www.w3.org/TR/REC-
png.pdf)

------
Grue3
One is vector-based graphic, the other is raster-based. Completely different
use-cases. APNG vs GIF is a better comparison.

------
mhd
I remember SVG being introduced way back when as the solution to some of our
HTML problems, and only in recent times is it gaining some momentum.

That probably means that VRML will become a thing in 2020.

------
josteink
I see Adobe tools mentioned, but what _free_ (as in FOSS) tools exist to work
with animated SVGs?

~~~
premasagar
As well as snap.svg, you may want to take a look at Pablo (I wrote it). It is
for SVG manipulation and includes some animation methods [1] that utilise CSS
or JavaScript callbacks (also SMIL which is recently deprecated).

[1] [http://pablojs.com/api/#Animation](http://pablojs.com/api/#Animation)

------
GvS
Every time I tried SVGs over past years there was always some problem with
them. They didn't work in one browser, required some different format in
other. I hope it will work flawlessly in all browsers some day because it's
really nice format.

------
TeeWEE
This is all known stuff right. Its basically vector format VS bitmap format.

------
nipponese
Browser support: do u haz it?

~~~
graham-miln
Yes, SVG appears widely supported. See
[http://caniuse.com/#search=svg](http://caniuse.com/#search=svg)

