> On the other hand, using the earliest of GUI's as an example is misleading since the improvements I mentioned will require about 1,000 times the memory. 800x

> On the other hand, using the earliest of GUI's as an example is misleading since the improvements I mentioned will require about 1,000 times the memory. 800x600px @32b was my favorite resolution & depth for a long time. 800x600x32/8 (800 pixels x 600 pixels x 32bits per pixel / 8 bits per byte) = ~1920000 bytes. Call it just under 2MiB. But 4K? 3840 x 2160 x 32b / 8 = 33177600 ... or just around 32MiB... around 16x the size. No, it does not require 1000 times the memory. It requires only about 16x the memory. Where memory is being lost is in massive amounts of inefficient languages copying and duplicating huge swaths of images (and tons of other datas too) that will never or rarely be used. Want a transparency on the window? Well now you have your image, the background image, and the real blended image. Want to show bunches of pretty little custom images? Each of those comes in, and some of them aren't even visible! But they still need to be loaded up. And that doesn't even talk about the slowness of the application. Tons of IPC communication going on to enforce sandboxing, instead of just directly doing whatever it is that needs to be done. In-process multi-threading models with inefficient languages exacerbate it. Inefficient design with huge layers of abstractions to support a fifty bajillion different ideas for how a user might want those pictures shown (oh, you want big icons but another user wants little pictures; you want light colors, another wants dark colors, and a third wants custom colors...; different fonts, different etc...). And that's just looking at images. What about datas? Gotta hold all of those APIs and telemetry somewhere. Gotta cache them so you don't have to request it again. Gotta hold it in memory because disks are slow. Gotta keep all of the metadata too. Might as well put it into a sqlite3 database and make it easier to manage! Or maybe the developer can just store it all in a linked list and look it up as needed... And what happens when you run out of memory? Goodness that's annoying and difficult, especially in a terrible language, so just don't worry about it. Just allocate something new and let the garbage collector... collect your garbage that you've strewn all across the user's machine. Who cares if it's "slow" as long as your application doesn't crash? Need to render a new image? Best to render it from a template image, so now you're holding even more images and also allocating new ones every time you need to render stuff. Except that it's all done in CSS by the kids these days, so the template image isn't even an image... it's text... to be rendered by the CPU. Yes, cool. No, not fast. All of that ends up being on top of terrible "cross-platform" frameworks to make it cheaper (to the developer) to build the damned software. Why are computers so slow and bloated these days, anyway? It's certainly not because computers are slow and bloated.