|
|
|
|
|
|
by Gormo
839 days 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. |
|
|
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