3 ms·

While there is some truth to your point, you have to remember that resolutions where already pretty high in the 90s (CRTs, not LCDs); I remember using 1024x768

While there is some truth to your point, you have to remember that resolutions where already pretty high in the 90s (CRTs, not LCDs); I remember using 1024x768 as the standard, and it only required something like a 2MB VGA card. Part of the reason we had these huge framebuffers and still work with a minuscule amount of RAM is cultural. Programs (GUIs, games) would just NOT store a bazillion copies of the framebuffer, but rather only one or two (and mostly in the video card itself), and would prefer to scroll or redraw rather then to save/restore contents of the framebuffer whenever possible. One pretty obvious example happened in the 2000s where the major 3 operating systems switched to desktop compositing almost simultaneously. You suddenly jump from requiring memory for just one framebuffer to requiring memory for one framebuffer + a copy of all the windows you have created.

alchemist1e9 3y ago
I find this line of thinking very interesting. From above: > And this leaks into everything - just keeping a single display fed at 60 Hz takes up 2 GByte/s of memory bandwidth, more than half of what your dual-channel RDRAM setup could even deliver. Does anyone know how practical are any countermeasures, for instance is tinycorelinux tinyx working for anyone? I’m particularly interested in all the used Chromebooks floating around and what are some ways to trick them out with customized Linux.
saltcured 3y ago
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.

alchemist1e9 3y ago

I find this line of thinking very interesting. From above: > And this leaks into everything - just keeping a single display fed at 60 Hz takes up 2 GByte/s of memory bandwidth, more than half of what your dual-channel RDRAM setup could even deliver. Does anyone know how practical are any countermeasures, for instance is tinycorelinux tinyx working for anyone? I’m particularly interested in all the used Chromebooks floating around and what are some ways to trick them out with customized Linux.

saltcured 3y ago

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.