[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]

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]

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