Hacker News new | ask | show | jobs
by kwhitefoot 1255 days ago
It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's. I wrote considerable amounts of code on the Z80 Apple II add on in the early '80s and never felt that the editor was too slow. My wife wrote a novel on our Osborne 1 (CP/M, Z80, 5 1.4 inch floppies) in Wordstar. Speed was never a problem for editing.
2 comments

> It's amazing then how much writing of both code and prose I and many others did on machines that were much less capable than today's.

Sure, on machines with low resolution screens with simple fonts and no anti-aliasing. I'm not saying accelerated graphics are necessary for text editors today, just that the context has changed considerably so the comparison isn't obviously fair.

Are you really trying to say that 100 times the pixels (and a lot less in a window that isn't full screen) cancels out 10,000-20,000 times the CPU power (per core)?
CPU speed isn't the limit, memory speed is. Apple II's 1MHz to DDR4's 1600MHz is 1600x increase, so more modest than CPU gains.

Apple II's display was 280x192 with 6 colours in high res mode, which is ~107kB of raw pixel data (Apple II didn't store this all in RAM). An RGBa display at 1080p is least 105MB of raw pixel data. That accounts for the 1000x difference right there. Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.

Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:

https://danluu.com/input-lag/

You are conflating a lot of different things here and some of your math is off.

First, 1920x1080 pixels times 3 bytes for RGB is about 6.2 MB. I'm not sure where you got an alpha channel from. Also an entire screen of pixels isn't being copied from memory to refresh a text buffer.

Second the Z80 couldn't transfer a byte every cycle so that's 500KB/s.

Third, DDR4 doesn't have a bandwidth of 1.6 GB/s, which would be absurd. We can call that about 20 GB/s - https://www.transcend-info.com/Support/FAQ-292

The comparison for memory pixel data is 6.2 million / 107,000, which is 58. The comparison for memory bandwidth is 500KB to 20 GB/s, which would be 40,000.

Add a few extra features like anti-aliasing, more sophisticated layout management, syntax highlighting, etc. and it all seems to track.

These don't have anything to do with memory bandwidth and are back to CPUs.

Finally, there are other sources of perceptible differences in UI/UX due to the growing depth of the software stack:

This doesn't have anything to do with anything in this thread. The original person said text rendering was expensive, that has nothing to do with input latency.

Bitmap rendering is incredibly fast. Old computers were so slow it was the only viable method.
So new computers are slow because it is no longer the only method? Do they spend a lot of time on each frame dithering over how to do it?