That's true for Electron apps. For other kinds of desktop app, it's mostly stuff like artwork, double buffers and fonts. Go profile a desktop app heap and see for yourself.

One of the main selling points of Turbo Pascal was OWL: the Object Windows Library, which was just a big OOP abstraction over Win16. Here's some sample code:

https://github.com/TeamVault/pascal-programs/blob/master/Pas...

Doesn't look radically different to how a GUI app that targets a native framework would look today. OWL added bloat to make developer lives easier. It was ever thus.

▲ BadlyDrawnBoy a day ago | parent [-]

I think its true for most types of modern development for apps with a UI, not just electron

>Doesn't look radically different to how a GUI app that targets a native framework would look today

Modern "Native" frameworks are part of the problem. I cant comment on Windows current state as I havent used Windows since I moved my gaming rig from Windows 7 to Linux many, many years ago but even then Windows frameworks were a complete mess

Take Libadwaita for example. I migrated an old, very simple disk image manipulation utility app last year from GTK2 to modern gnome. No change in capabilities, a simple clone in GTK4 / Libadwaita. It went from using ~19MB to ~185MB without any additional functionality simply by switching the "Native" framework

▲ kvemkon a day ago | parent | next [-]

> GTK4

After my comment https://news.ycombinator.com/item?id=49235430 I've investigated the high RAM jump issue a bit further. It turned out, 60 MB comes from MESA / video graphics driver, right after the first function call, that triggers OpenGL/... context initialization. Thus:

  GTK2 14 MB
  GTK3 24 MB
  GTK4 38 MB  (+ 60 MB video acceleration)

Looks a bit better. But we still need 98 MB total.

▲

direwolf20 17 hours ago | parent [-]

Maybe we should also ask ourselves why modern native apps need OpenGL when you used to get by with a framebuffer. You can do more things with OpenGL but are you actually doing those things?

▲

mike_hearn 12 hours ago | parent [-]

It's almost entirely about screen resolutions. In the Turbo Pascal era the screen probably had 640x480 pixels or 307,200 pixels in total. The screen I'm looking at now is 5120x2880 = ~14.7M pixels.

If an app is maximized it has to render ~48x more pixels per frame, probably with anti-aliased text which older systems didn't use. Doing that on the CPU is not only visibly slow in many cases, but a waste of CPU time that could be better used for actual app logic. OpenGL happens to be a convenient and portable way to get the GPU to do work for you, at the cost of some memory, so GL it is.

▲

direwolf20 3 hours ago | parent [-]

It doesn't render them. Framebuffer native apps back then didn't have enough memory bandwidth to change every pixel every frame either. They just changed the ones that changed. You'd probably still let the compositor use the GPU to drag windows around. They had that back then too, it was called accelerated blitting.

	▲	mike_hearn 2 hours ago \| parent [-]
		GL based widget toolkits only render the needed pixels too. It's good for saving battery but isn't enough by itself as it only works until the app genuinely needs to repaint the entire window. Think a text editor or IDE switching to a different file.

▲ mike_hearn a day ago | parent | prev [-]

Try GSK_RENDERER=cairo and see if it helps. I think the memory usage increase will mostly be GPU buffers. If GPU rendering isn't necessary for your app then it's pure bloat to use it, indeed. But with very large hi res screens it's often the case now that CPU rendering can't keep up anymore.

	▲	kvemkon a day ago \| parent [-]
		3 MB RSS less with GTK4 4.22.4 on Debian Forky (testing).