anyway, so, a lot of the disconnect in the conversation is that i was talking about the performance characteristics of 40 years ago, while you were talking about the performance characteristics of now. and the cost functions have changed significantly. it's still the case that you can display an uncompressed raster image on a raster device faster than a vector image, at least if it's already in your vram, and the extra cost of rendering vectors on a raster display is why vector images were comparatively little used in the 01980s, when all mainstream use cases of raster images used uncompressed images. but i agree that that's only minimally relevant to whether an svg or a png would be faster for a line-graphics timeline on a website!
with respect to current performance, i still disagree with this:
> Decompression time also scales much more significantly for larger raster images than computation time does for rendering vector images.
for all the compressed raster image formats i'm familiar with, decompression time is fairly precisely linear in the image size, either input or output. vector graphics rendering attempts to reach this ideal, but often fails, because in most vector formats there are interactions between objects that usually have to be taken into account in drawing. so they have to use all kinds of clever algorithms to approach the linear-time ideal which raster compression formats reach almost without effort, and those clever algorithms tend to have high constant factors
considering the 640×480 http://canonical.org/~kragen/sw/dev3/rc.png http://canonical.org/~kragen/sw/dev3/rc.png, which is produced by http://canonical.org/~kragen/sw/dev3/plotrc.py http://canonical.org/~kragen/sw/dev3/plotrc.py, which can also generate the same plot in eps, pdf, or svg. it ought to be close to a best case for vector rendering, imagemagick on my system takes 21 milliseconds to convert the png to uncompressed binary netpbm format (ppm p6, best of three tries); pngtopnm takes 29ms. generating encapsulated postscript instead and converting it with imagemagick, it takes 465ms. with pdf, 199ms. with svg, imagemagick takes 635ms, but that's obviously because it's badly implemented. (i just don't have a convenient way to benchmark the svg engines used in my browsers.)
apache batik's 'rasterizer' command takes 1294ms, and i thought maybe that was a question of jvm startup overhead, but actually, if i run it with a nonexistent filename as input, it takes only 205ms, so about 1100ms of that is actually processing the svg, so it's actually the svg processing that's taking the time. benchmarking programs in hotspot is riddled with reproducibility problems, though
so in this tiny, badly done benchmark, different vector formats came out as 22 times slower than png (eps), 9.5 times slower (pdf), 30 times slower (svg), and 52 times slower (svg in batik). i suspect that in my browser svg would be only about 4 times slower, which would optimistically mean that for images the size of my entire screen it would actually be faster if they were this simple; but i don't have a good way to prove it
i think what this shows is mostly that vector formats are not simple, not that they're inherently slow. but i don't mean 'simple' in the sense that 'they are ultimately always encoding a grid of pixel values', as you said; i mean 'simple' in the sense that the code required to display vector formats on a raster display takes a lot more effort to write. as a crude measure of this, we can compare the amount of code in the svg and png implementations i have installed here. png is about 340k, if we include zlib, which we probably should:
$ ls -l /lib/x86_64-linux-gnu/libpng16.so.16.39.0 /lib/x86_64-linux-gnu/libz.so.1.2.13
-rw-r--r-- 1 root root 219056 Nov 27 2022 /lib/x86_64-linux-gnu/libpng16.so.16.39.0
-rw-r--r-- 1 root root 121280 Nov 5 2022 /lib/x86_64-linux-gnu/libz.so.1.2.13
qt 5's svg implementation is 360k, but it is linked with, among other things, libharfbuzz (for text layout), libfreetype (for text rendering), libicu72 (i assume for text rendering), libpng, zlib, the zstandard library, and the brotli library
but all of that is just the file format — it doesn't even include the vector rasterization code! that's done by the graphics engine in qt core, which is vaguely similar to cairo or libart in that it implements things like path items, rect items, ellipse items, line items, text items, group items, rotation, shearing, scaling, translation, and a bsp tree index to make the aforementioned interactions between drawn items efficient
the other svg implementation i have installed is librsvg2, which is the implementation used by things like vlc, the gimp, gnome, r, netsurf, links2, and cairo. it's uh
$ ls -l /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.48.0
-rw-r--r-- 1 root root 11070952 Jul 30 2023 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.48.0
11 megabytes by itself, and it also links in libpng and zlib (and brotli, and liblzma, and harfbuzz, and pango, and freetype), plus cairo to do the actual rasterization, which is another 1.2 megabytes:
$ ls -l /lib/x86_64-linux-gnu/libcairo.so.2.11600.0
-rw-r--r-- 1 root root 1187432 Dec 9 2022 /lib/x86_64-linux-gnu/libcairo.so.2.11600.0
so maybe a good estimate is that png is 30 times simpler than svg and 4 times simpler than basic vector rendering
okay, one final reply
> 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.
it's not correct to describe prodigy as a 'pre-internet online service'. when prodigy launched in 01984 and got its first user, the internet had been operating for about 7 years and consisted of about 1000 hosts with somewhere on the order of a hundred thousand users. i don't think prodigy ever, at any point, had more users than the internet; it was under half a million users in 01990 (when the internet reached three hundred thousand hosts, most with many users), and i think it was under a million users even at its peak, when its scumbag employees were claiming prodigy had invented the internet and deleting any user messages that criticized a prodigy advertiser or mentioned another user by name
it's also not correct to say that naplps predated gif by nearly a decade. naplps was defined in 01983, gif in 01987. four years is not 'nearly a decade'
finally, although i'm less certain about this part, i don't think it's correct to say that 'ripscrip achieved near universal adoption in the bbs world', ever. ripscrip didn't even exist until 01992, at which point lots of us even in the usa were still running bbses on things like a commodore 64 (which was still being sold until 01994) or a 286. i used a dozen or so bbses in albuquerque at that time, and none of them supported ripscrip that i can recall at all. my non-biological sister met her boyfriend and later husband on one of the big commercial bbses in town, a chat-oriented thing. ansi art was a huge deal, but ripscrip was very little used. and then the internet went mainstream in the usa in 01994 due to the lifting of the nsfnet aup and the launch of netscape; even windows supported it late in the next year, at which point netscape had already gone public. see https://www.zakon.org/robert/internet/timeline/ https://www.zakon.org/robert/internet/timeline/
try searching online for archives of ripscrip art and ansi art. the amount of ansi art even just from 01995 is orders of magnitude bigger than all the rip art that has ever existed
> 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.
this also contains some significant mistakes
as i recall it, gif was initially used primarily for line art, which could indeed be quite complex. myself, i mostly used it for line art and fractals. scanned photos were fairly limited because in 01987 ram was expensive, so most people's framebuffers were pretty small; a cga in graphics mode could only display 4 colors at once, an ega (or cga in text mode) only 16, and a macintosh or hercules or sun bwtwo only 2. you really want at least 256 colors for decent scanned photos, and that's the maximum that gif supported or supports even today. people who were scanning photos up to about 01990 were mostly using high-end graphical workstations and not using gif
gif's compression also doesn't help very much with scanned photos, and it doesn't help at all with 256-color scanned photos. even png is less bad here because, even though the paeth predictor was designed for low-color-depth images, the paeth predictor residuals for color gradients are much lower entropy than the raw pixel data
icons for use in graphical interfaces were generally not stored as gifs, but as uncompressed raster data (.xbm, .ico, macintosh images in the resource fork) and generally were not uploaded and cached locally but rather part of the software that used them. most icons were 16×16, and a 16×16 uncompressed icon in two colors is only 32 bytes, which is smaller than literally any image in gif format
i hope this thread has been informative
i certainly agree that now uncompressed images are little used, but at the time i was talking about, when cpu load of still image encodings was a major concern, compressed image file formats basically did not exist
naplps is 01983, gif 01987, prodigy half a million users more or less, many fewer than fidonet, usenet, or university internet accounts at the same time
you may be interested to know that i reverse engineered a vector font from an imlac vector terminal from 01973 a couple months ago http://canonical.org/~kragen/sw/dev3/imlacparse.py http://canonical.org/~kragen/sw/dev3/imlacparse.py
will have to answer more at length with a better keyboard. i appreciate your comments
so, i think one of my errors was to not start by acknowledging that this is absolutely correct:
> 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.
this is in fact one of the major points coueignoux makes in his 01975 doctoral dissertation, which knuth credited (apparently erroneously) as being the origin of the idea of outline fonts. the letterforms of coueignoux's 'france' system weren't the first vector graphics file format (that would probably be g-code) but they were important pioneers
there are other things i take more issue with. you said:
> 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.
and this is somewhat true. what i was taking issue with was mostly something you didn't actually say and probably don't believe, so it was pretty unfair of me to project it onto you; i thought you were saying that displaying vector graphics on raster displays in the 01970s and 01980s was faster than displaying raster graphics on raster displays. but you said where storage, memory, or bandwidth were constrained, not cpu time. and of course it is absolutely correct that in the period of time when naplps (01983), king's quest ii (01985), and ripscrip (01992) came out, people did often use vector graphics to save storage, memory, or bandwidth. that wasn't the only reason they did it (for example, i used autocad on an ibm pc xt, which used vector graphics because the entire computer with its crude cga screen, second text-only screen, keyboard, and mouse was only a way to coax the pen plotter to plot out a high-quality drawing) but it was a common one
if you had an actual vector output device like the pdp-1's scope, the computer-output-on-microfilm device for which hershey designed his now-ubiquitous fonts, the imlac, the tektronix 4014 serial terminal, a pen plotter, or the evans & sutherland lds-1, all of which are from long before leisure suit larry, using vector graphics could save cpu time too. these definitely were not 'limited to industrial equipment (old-school oscilloscopes, radar monitors, etc.) niche CRT-based arcade games, and the occasional novelty laser display,' but they were mostly expensive and specialized. however, i had a cheap letter-sized hp pen plotter at home when i was a kid, and bought another used one to play around with in the late 01990s
i have a hard time describing those lying scumbags prodigy (01984) or the naplps they used (again, 01983) as 'early graphical frontends to network resources'. people had been providing graphical frontends to computer network resources since nls (01969) if not sage (01958) — generally using vector displays up to the 01970s, at which point there was a major shift toward raster-display systems like the knight tv (early, about 01974) https://gunkies.org/wiki/Knight_TV_system https://gunkies.org/wiki/Knight_TV_system
flash, of course, is from 01996, so it's not an early graphical frontend to networked resources by any stretch of the imagination; it didn't exist until six years after the world-wide web. i agree that being the only way to do vector graphics on the web was a major reason people used it. (the only way except vrml, which nobody supported, and starting in 01998, vml, but only in msie.)
but people used flash for many other reasons as well. text layout in flash is much simpler and more predictable than in html, though, by the same token, supports graceful degradation and responsivity very poorly. if flash was supported at all, you could count on your fonts being supported, because you could embed them in the flash file, which html couldn't do. animation in flash doesn't require programming, so it was much more accessible to nontechnical users. when you were programming, until chrome launched (in 02008), actionscript was much faster than browser javascript. flash could play sounds; browser javascript couldn't (well, there was <bgsound> and <embed>, but those weren't really suitable for game sound effects or synchronizing audio with animation). flash could play video clips; browser javascript couldn't
given these vast differences between flash and the browser environment outside of flash, i don't think it makes sense to reduce them to vector vs. raster. the reasons allyourbase or strong bad email or thousands of terrible brochureware ecommerce sites had to be done in flash instead of html had little or nothing to do with vector vs. raster