I've posted about this before, but people forget that we used to worry about bit depth for the framebuffer and available VRAM. And back then, such a low-RAM car

I've posted about this before, but people forget that we used to worry about bit depth for the framebuffer and available VRAM. And back then, such a low-RAM card was only doing 2D acceleration at most, with a little offscreen buffer for fonts and sprites that would be blitted into the active framebuffer or composed at the DAC by the card itself (like the cursor). Just for your example, 1024x768 would require a minimum of 3 MB just for a single buffer of pixels if stored with today's typical 4-byte RGBA and updated in immediate mode. A double-buffering technique would take twice as much. Most often, we were using either 8-bit pseudo-color mode or maybe 2-byte 15-bit true color with only 5 bits per RGB component and no transparency. A 2MB card might support 1024x768 in 15-bit mode or 1280x1024 in 8-bit mode. I distinctly remember on my first serious Linux machine when I downloaded a single large JPEG image from an academic site and displayed it with the "xv" command which was the go-to image viewer at the time. It required virtual memory swapping because the image buffer to store the decoded image would be larger than my entire 20MB of system RAM. This was an unusual image, interesting to me mostly for this fact. As I recall, it was a high resolution scan of an ancient manuscript.