3 ms·

On the surface, this doesn't seem quite right. Vector graphics were used ubiquitously in legacy applications where storage, memory, or bandwidth were constrain

• kragen 3y ago
  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 3y ago
    > 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 3y ago
      Even then, it was the OS rendering the image directly into the framebuffer, while applications that included raster graphics still had to output them via an API exposed by the OS. The only thing that's going directly into the framebuffer is the fully rendered screen, which in a GUI environment usually contains much more than the contents of a single PNG or SVG file. In the context we're discussing, where the image is an inline PNG on a web page, the browser has to download the image, decompress it, apply relevant transformations defined by CSS or element attributes, render the HTML including the image, then pass the rendered window output to a display API exposed by the OS. Far from just dumping an uncompressed raster image directly into a framebuffer -- although that sort of thing was definitely common on single-tasking non-GUI platforms in the past.
      • kragen 3y ago
        yes, i agree that the graphics pipeline of current browsers is a lot heavier weight, so file format efficiency is a smaller part of the picture when rendering directly into the framebuffer was a win depended a lot on the relevant memory bandwidths. vram access being slow is not a new thing this millennium both microsoft windows and x-windows did support hardware acceleration of drawing operations, and that was crucial for getting good gui responsivity on platforms below about 64 mips. hardware acceleration of drawing operations is kind of like vector graphics file formats but not the same thing unless the file format is wmf, so you had to do things like ripscrip on the cpu. in the 64-512 mips range that is faster than an 80486 but slower than a raspberry pi 1, you can draw a totally responsive megapixel gui entirely in software. the crucial equation is that a 256-color megapixel frame is a megabyte and you need at least 20fps to be usable (50 without double buffering), so you need 20 megabytes a second of bandwidth to the vram the isa bus gave you 8, so you were stuck with either partial screen updates (only drawing changed regions) or hardware acceleration. other platforms were somewhat better but mostly only a little. hardware acceleration could typically do bitblt but not polygon fill, so vectors lost again. vlb came around in the 80486 timeframe and changed things a lot the first versions of both microsoft windows and x-windows supported graphics file formats but no compressed formats