6 ms·

> 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

by Gormo 3y ago

> 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.

kragen 3y ago
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

by Gormo 3y ago

kragen 3y ago

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