[evrimoztamur]

With SVG support at a near-full coverage (and 99.99% for Canva's user base, https://caniuse.com/svg) you do wonder why we see less SVG for graphics like this. It's literally easier to export, and no harder to import than PNGs.

[Etheryte]

From personal experience and having been burned by odd SVG bugs too many times over the years, a dumb image is simple, it works and you know that it works. I only reach for SVG when I need to do something that other formats cannot.

[Hendrikto]

> I only reach for SVG when I need to do something that other formats cannot.

Like rendering actual text?

[dunham]

At one point, SVG couldn't do that. It was a long time ago, but I recall not being able to use SVG to render sideways text because the text tag wasn't supported by browsers.

For IE, we had a PNG font that we displayed slices of, and then we migrated to rotation css as various browsers supported it. (I think IE was the last holdout, but it's been a while.)

[jacobolus]

From one implementation to another and depending on the way the SVG was encoded, text in an SVG often does not look the same for different viewers. This can seriously mess up the layout of diagrams, etc.

[pennomi]

Plus SVG can’t properly wrap text, which matters for some use cases.

[int_19h]

If you're rendering a PNG, you're already doing layout, so you might as well still do it but at least keep the individual glyphs as, well, glyphs (so that they scale to high DPI etc).

[dylan604]

My experience as well. Using an SVG as the source of an <img> element seems to have less issues, but that essentially reduces the benefit of an SVG to just a small file size image without scaling issues.

To use an SVG as an actual element, it gets way more complicated than your average Wordpress user is going to want to deal with. It's one of those very interesting formats that can do some very impressive things...that very people want/need/use.

[int_19h]

"Without scaling issues" is a huge benefit in its own right, though. That alone is a good reason to use it.

[gwern]

So many bugs. The background will break in dark-mode, or the foreground. The bounding box will cut off the image contents. You export in SVG to get nice text rendering and everything carefully aligned, and it looks in Chromium the way it did in Inkscape... but then in Firefox everything is misaligned, defeating the point compared to if you had just used a PNG. It doesn't work as a social media thumbnail. And so on.

[i80and]

So for a contrasting anecdote, we've used SVGs for years in production on a high traffic site, using an automated Inkscape pipeline to turn text into plain paths, and it's worked perfectly

[simpaticoder]

The decision then is between building "an automated Inkscape pipeline to turn text into plain paths" and creating a PNG.

[i80and]

For diagrams, PNGs just are not a good choice. We did this as a response to mainstreaming high dpi displays back when Retina hit the market.

It's been a big success. The resulting SVGs are significantly smaller in filesize than PNG, and are crisp and readable no matter how the user zooms in.

The path conversion is a single inkscape command line invocation. It's worth doing.

If it comes out of a vector application, you likely don't want to rasterize it for distribution.

[gwern]

(These are just the ones I recall offhand from personal experience on gwern.net using SVG in quite limited ways, mostly just for the link-icons.)

[kungreke]

Exact same reason jpgs and gifs were the standard for such a long time.

[vundercind]

Vector graphics were (are) expensive on the client side. Part of why we didn’t use them is that they could be noticeably slow.

[Gormo]

On the surface, this doesn't seem quite right. Vector graphics were used ubiquitously in legacy applications where storage, memory, or bandwidth were constrained. Most early graphical computer games were only viable due to vector rendering techniques (Sierra's adventures, for example), and lots of early graphical frontends to network resources were entirely vector-based (NAPLPS, RIPScrip, etc.); Flash was primarily vector-based.

It's the widespread use of raster graphics for everything that's relatively more recent, and this has been enabled by the use of complex compression to achieve reasonable file sizes for large images. Those compression algorithms make a similar tradeoff to vector formats in that they save space at the expense of computation time.

I'm not sure if anyone has done any organized experiments, but it would be interesting to see some stats on render time of SVGs in comparison to decompression time for PNGs or JPEGs. My suspicion is that relative performance is highly context-specific, and that there's no general factor that makes either consistently faster than the other.

However, vector graphics do have the advantage of having the ability to be displayed at different resolutions -- the 'S' in 'SVG' stands for 'scalable' -- whereas raster images need actually to be larger to maintain clarity at higher resolutions, increasing transfer and decompression time.

So as display res increases, the render time for PNGs or JPEGs would be expected to increase much more steeply than for SVGs, meaning that many for many practical use cases, SVG is likely the more efficient option.

[kragen]

i understand your confusion, because there are many different axes of performance in play here

vector graphics will almost always be smaller than raster graphics as long as what you're displaying can be represented in a vector format at all. the only exception is when your vector graphic contains more detail than your display resolution can render. consequently, virtually every graphics application of electronics was done first with vector graphics and only later with raster graphics. the only exception i can think of is television. but radar, cad, guis, fonts, video games, first-person shooters, computerized typesetting, pretty much everything was done first with vector graphics and only later with raster graphics

however, when you're rendering to a raster display, raster graphics are always faster unless a bandwidth constraint bites you. the last step in rendering vector graphics is to copy the rendered image into the framebuffer, which is the only step in rendering raster graphics. (of course, arbitrary decompression can be arbitrarily slow; png is as fast as gif, while jpeg is much slower, and jpeg 2000 is slower still. it's easy for a vector format to be faster than jpeg 2000 and in many cases even jpeg.)

your historical accounts are a bit wrong. naplps and ripscrip never achieved significant adoption because gif was already widespread, and people used plenty of raster graphics in flash

the bigger issue is that when you don't control the renderer, vector graphics are not only slower (which is often no obstacle to interactive use now that our personal computers run ten billion instructions per second instead of one million like when ripscrip was launched) but also more unpredictable in speed. an svg that one renderer handles fine may bog down another one. generally speaking that isn't a problem with raster formats, not for any deep theoretical reason but just because they're simpler

i do agree that vector rendering is the more efficient option for many practical use cases, though

[int_19h]

> the last step in rendering vector graphics is to copy the rendered image into the framebuffer, which is the only step in rendering raster graphics

Today it is, but historically that was not the case. Even as late as early 00s, most OSes rendered vector primitives directly into framebuffer, without a compositing stage. That's how e.g. Windows could be so fast on hardware that was slower than today's Raspberry Pi.

[Gormo]

> however, when you're rendering to a raster display, raster graphics are always faster unless a bandwidth constraint bites you.

I don't agree with this at all, unless you're hyperfocusing exclusively on the path from VRAM to the display hardware, in which case, you're always outputting to a raster display device no matter what -- physical display hardware that draws vectors natively has been rare, limited to industrial equipment (old-school oscilloscopes, radar monitors, etc.) niche CRT-based arcade games, and the occasional novelty laser display.

> the last step in rendering vector graphics is to copy the rendered image into the framebuffer, which is the only step in rendering raster graphics.

This is where I feel like you're being overly particular in your analysis, because there are almost no mainstream use cases in which uncompressed raster graphics are being stored or transmitted. Certainly the case that sparked this particular subthread -- displaying a line-graphics timeline on a website, and debating whether SVG would have been a better solution than the PNG that was used -- the relevant performance metric is overall time-to display for images of equivalent visual quality.

The comparison here is between the time it takes to transmit, decompress, and display a PNG vs. the time it takes to transmit, render, and display an SVG. The 'display' phase factors out, because once the final image is rendered/decoded, the process to send it to the display hardware is the same. So what matters is the transmission time needed to send the file plus the computational time necessary to decompress (for raster) or render (for vector).

And my point is that both of these scale much more rapidly for raster images than for vector ones. File sizes are larger for higher resolution images, so they take longer to transfer, whereas the same vector file can be rendered at any resolution, so transfer time is constant. Decompression time also scales much more significantly for larger raster images than computation time does for rendering vector images. So at higher resolutions, all things being equal, I expect vector graphics to perform faster more often than raster graphics do.

Obviously, there are lots of other granular variables, so this isn't a deterministic rule. A massively complex SVG, e.g. with tens of thousands of polygons, curves, and fills, will likely be slower to render than a high-resolution PNG of the same will be to decompress.

> an svg that one renderer handles fine may bog down another one. generally speaking that isn't a problem with raster formats, not for any deep theoretical reason but just because they're simpler

In theory, that's true. In practice, there are a small number of renderers in widespread use, all of which have testable performace. In this case, we are talking about web browsers, nearly all of which use one of two renderers.

> generally speaking that isn't a problem with raster formats, not for any deep theoretical reason but just because they're simple

They're simple in the sense that they are ultimately always encoding a grid of pixel values, but they're not necessarily computationally simpler due to the amount of processing necessary to compress/decompress them.

> your historical accounts are a bit wrong. naplps and ripscrip never achieved significant adoption because gif was already widespread, and people used plenty of raster graphics in flash

NAPLPS defined the entirety of the user interface to one of the major pre-internet online services starting in the 1980s (Prodigy), and itself predates GIF by nearly a decade. RIPscrip achieved near universal adoption in the BBS world for a few years prior to the internet taking off. These solutions were the only effective way to create full-screen graphical environments for bandwith-constrained remote applications at the time.

GIF was first developed in 1987, and was initially used primarily for file uploads of images that were inherently raster (e.g. scanned photos, complex artwork, etc.) or for small icons to be uploaded once and cached locally for use in graphical interfaces. And GIF was only viable for these uses because of its compression.

Flash was primarily a vector format (into which compressed raster images could be embedded), and had huge adoption as a vector animation tool on the early web precisely because there was no other way to do vector graphics on the web, and bandwidth was neither fast enough nor codecs efficient enough to be viable for these use cases until very recently, relatively speaking.

[gpjanik]

That's just incorrect.

Every letter you're looking at now is vector and no different in terms of performance of rendering to SVG.

[dhosek]

Not quite. A type renderer will cache the bitmaps for each individual letter so it only needs to calculate the vector to bitmap activity once for each individual glyph. This will also be the case if your SVG renders text as text (potentially with embedded fonts), but if it instead has that type as outlines then all the outlines need to be rendered and there’s no cache saving for typesetting, e.g., XXX

[SSLy]

> A type renderer will cache the bitmaps for each individual letter so it only needs to calculate the vector to bitmap activity once for each individual glyph

not if you do subpixel aliasing

[gpjanik]

You can literally make that entire graphic a font glyph. I understand there's caching, but your point doesn't really apply to the above example.

[graftak]

Perhaps but on my phone I can zoom in and out real fast on a page of text without a single glitch or hiccup and there’s no way a >512px bitmap for every character displayed is used.

[vundercind]

I was there.

Vector graphics were avoided on the Web because they made pages perform poorly. The advice was widespread, and it was easy to see why if you did encounter an SVG on the Web.

We couldn’t draw with CSS yet, but in the earliest days of that being possible, it was slow, too.

Moore’s law outran those problems, but I suspect our collectively dropping the old “raster = considerate to your user” attitude (including and especially in what we do with CSS these days) is an under-appreciated factor in the astonishingly terrible performance of the modern Web—Javascript gets most of the blame, but I think a lot of it’s giant CSS engines and doing so very much more runtime rendering on the client.

[lifthrasiir]

Kinda because it's harder to make a good SVG editor, and also a clean SVG is substantially harder to export and thus SVG is only seen as an authoring format.

[Zetobal]

The same goes for webp normal people don't know what to do with them.

[kragen]

i was appalled to discover yesterday that when i did a simple plot in matplotlib the resulting svg was mostly letterforms for deja vu sans expressed as svg paths

at least it did subset the font

[jacobolus]

Try encoding it the obvious way as text instead and view your SVG file on different renderers, and you will often find that they messed up the fonts/text layout.

This is a defensive practice to ensure that your plot will look the way you intended.

[kragen]

yes, i understand why it's done, and i agree that svg doesn't offer a better alternative. that's because the only fonts svg guarantees the existence of are Serif, Sans-Serif, Monospace, Cursive, and Fantasy, none of which have guaranteed metrics. the reason i was surprised and appalled is that both of adobe's previous standards in the line from which svg descends (postscript and pdf) avoid that problem by guaranteeing the availability of certain core fonts with (in practice, though not in theory) well-defined standard metrics, and it makes svg a much worse standard for small images that include text

with pdf.use14corefonts and ps.useafm turned on in matplotlib, my plot from http://canonical.org/~kragen/sw/dev3/plotrc.py is 8k as eps, 9k as pdf, 21k as png http://canonical.org/~kragen/sw/dev3/rc.png, and 24k as svg

(with optipng the png shrinks to 16k but you could definitely optimize the other formats too; matplotlib fills all of them with ridiculous amounts of bloat. but the embedded font is most of it, and it's only necessary in svg)

like, you really have to fuck your vector file format up for it to make a simple line plot format larger in it than as an antialiased png

or for it to make it three times larger than a fairly shitty eps or pdf

i like svg a lot (it's replaced postscript for me as the language i use for easy 2-d vector graphics) but it has some really serious deficiencies. this one is news to me; the other one i've run into is that there's no defined real-world scale, so i can't send an svg to a laser-cutting shop and ask them to cut it out at 1× or 2× scale. i have to use pdf or eps or dxf for that

[xcdzvyn]

This was downvoted but I think it's true. I find it way easier to throw something together in a raster editor than e.g. Inkscape.

I want to draw. With pixels. Not huge bezier curves.

[al_borland]

I took the time many years ago to learn how to effectively draw with bezier curves. It was not time well spent. A good tool in my tool belt for the moment, but it was very much a use it or lose it skill. I tried to do something recently and it was like starting from square one, so I just used raster. Unless someone is doing this stuff professionally everyday, or they are really into it as a hobby, it’s not worth it.

I assume this is simply a software problem that could be solved with a better UI, but who knows if that will ever be solved.

[wongarsu]

On the other hand the people doing this professionally everyday are producing mostly vector graphics, just in Illustrator rather than Inkscape. They still export as png or jpeg, the vector versions only go to print (in formats like eps or pdf, not svg)

[dhosek]

I always preferred working in Illustrator over Photoshop back when I did more design work, but then I was also almost always targeting print.

[egypturnash]

I work with Illustrator on a daily basis. Drawing everything with the pen tool is about as effective as opening up a 300dpi canvas in Photoshop and placing every pixel by hand with the pencil tool. There’s a bunch of tools for creating and editing paths at a higher level than thinking about every control point, just as Photoshop has a bunch of tools for creating and editing huge numbers of pixels in very complex ways.

It is useful for me to know how to think about individual control points, but it is rare for me to need to do this.

[al_borland]

Things have probably improved, and/or dedicated vector apps have better options I haven’t invested time it. Learning curves abound…

I did this in Photoshop so I could improve my selections and make them smooth. This was also back around 2006 if I had to guess. At the time, when I looked up what to do, all I found was learning how to use the control points, so that’s what I did.

What would be a keyword to look for to find the more modern way, if I’m not looking to go down a rabbit hole or learning all the possible options to find those bits?

[evrimoztamur]

I actually use Inkscape religiously for making diagrams or even UI mockups, an particularly in love with Bézier curves. To each their own!

[eurekin]

Another fellow Bezier enthusiast here!

I fell down deep into the rabbit hole of Beziers in the Rhinoceros modelling app. There is something special about clean higher order curvature continuity across shapes. It's simply beautiful.

That said, I have big issues with learning any other tool. So much of the app interface learning was required to be able to freely draw... I really do see, why the bitmap simplicity wins over in "I just need to have it done; needs to be published by x" cases

[oefrha]

You need to export all the text as curves to get predictable font and rendering (the fonts used in the image obviously aren’t your regular web-safe fonts), and that’s not gonna be small with a lot of text.

[chiefalchemist]

On Canva free plan, afaik, there is no export to SVG. If there is, I can't find it. Maybe the paid tiers have it? IDK.

The point is, they likely used their own tool and that tool's support for SVG is lacking.

[bombcar]

Even when "export to SVG" is available, you often have problems if you can't force it to export (amusingly enough) fonts as vectors instead of referring to fonts by name, etc.

Makes the file larger, but makes it render (mostly) correctly on any system. There can still be discrepancies, however.

[input_sh]

I know that transparent PNG exports are paywalled, I don't think they offer SVG.

[chrisweekly]

See also https://slides.com/sdrasner/svg-can-do-that which despite its age (over 6y!) is still impressive.