[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