Hacker News Reader

Comment by imoverclocked | Hacker News Reader

I think you are actually reinforcing the point: Software has gotten very slow and does a whole bunch of who knows what.

Try using any of that 25-year-old software with accessibility devices, or at any DPI scaling other than 96x96, or split between two monitors with different refresh rates (or worse yet, two monitors connected to two different GPUs), or with sound or 3D accel that works over RDP, or with an RTL UI language. Those are some of the many "whats" that you get batteries-included in modern OS UI frameworks in exchange for the added overhead.

> or worse yet, two monitors connected to two different GPUs

This was a great feature of the Macintosh II in 1987. Sad that it's not ubiquitous yet. (Even modern Macs snap apps to one monitor or the other, so no video walls.)

> Even modern Macs snap apps to one monitor or the other, so no video walls

Linux, and I believe Windows as well, can display windows across different monitors just fine. But sometimes the monitors are too different, and part of the window gets ugly. Probably a blocker in Appleverse.

Those will maybe account for 2x slowdown if we are being generous.

The vast majority is just bloat. Unimaginable bloat, hundreds of levels deep.

I'm sure you're right in what you say, but this is not the reason modern acrobat is slow. I'm sure you could build a modern and accessible app that starts and loads the requested PDF snappily to show it, but acrobat will also (iirc) have some cloud integration now for storage and a bunch of the features they offer are gated behind some sort of subscription, the status of which I would guess is loaded on startup, probably along with a bunch of other stuff.

The hardware is not a bit faster. It is many order of magnitude faster.

I can play video games at 4k 10bit HDR 120Hz with a 1kHz mouse polling rate. I can copy data at 10Gbps across computers via 30m of copper. I can transfer at 1.3Gbps through wifi.

But it takes 250ms for the f'n calculator to start up on a good day?

This is a general issue to all modern software.

Although it's true that maintained UI frameworks have features less-maintained UI frameworks don't, this isn't really the cause of the slowdowns. Those features are all edge cases that aren't in use most of the time, by most users, and so shouldn't be incurring any significant performance hit on the regular paths.

And you can certainly have such features in modern / fast frameworks. Take a Java Swing or JavaFX app and compile it with GraalVM Native Image. The framework dates from the 90s but is maintained because JetBrains relies on it. It supports hi-dpi displays, accessibility apps, multi-monitor rendering and so on. And when natively compiled, it will start in the blink of an eye.

Can you actually compile Swing or JavaFX with GraalVM? I have only ever heard anecdotal evidence of that, even though I have known people from the Graal team itself.

Like, there shouldn’t be anything fundamental that prevents it from working (it just has platform specific native dyn libs which works fine with graal), but never seen an example, so I would appreciate a pointer.

Haven't tried it, but looks like you can: https://www.praj.in/posts/2021/compiling-swing-apps-ahead-of...

Sure. For JavaFX see here:

https://github.com/gluonhq/substrate

Sibling gave a link for Swing. I've also seen it done for Jetpack Compose but that's definitely more experimental.

None of this stuff is very smoothed over though. There aren't many people doing it. But, the results are pretty magical.

Reply on news.ycombinator.com