7 ms·

I poked around on an old Indy at a vintage computer show a couple years back, and the main takeaway I had was, “holy crap the UI elements feel instantaneous.”

I poked around on an old Indy at a vintage computer show a couple years back, and the main takeaway I had was, “holy crap the UI elements feel instantaneous.” I know it’s been posted here many times about how computers have become perceptually slow, but that Indy after a couple minutes of poking around really drove the point home in a way that no numbers ever could. Computers have gained a lot, for sure, but they’ve also lost a lot. I wonder if it’s even possible to make a modern computer fast in a way that feels fast again.

walkingolof 6y ago
It would be interesting to measure this perceived performance with a camera to get hard numbers.
- still_grokking 6y ago
  https://danluu.com/input-lag/ https://danluu.com/input-lag/ https://news.ycombinator.com/item?id=16001407 https://news.ycombinator.com/item?id=16001407
whoopdedo 6y ago
There was a revelation a while back that instantaneous UX can be detrimental. If the action occurs so quickly that the users can't see it happening, they have a tendency to assume it didn't happen. Programmers had to introduce intentional latency through elements such as the file copy animation.
- blattimwind 6y ago
  I disagree. What you describe is a problem of interaction design founded on bad assumptions; with good interaction design I don't have to show the user that the computer is doing something for the user to be able to tell it happened. This is a problem of the system not showing its state transparently and relying on the user to notice a change in hidden state indicated by a transient window. Windows Explorer gets your particular example right: When you copy a bunch of files into a folder, it will highlight all of the copied files after it is done, so it doesn't matter if you saw the progress bar or not.
- derefr 6y ago
  That was indeed a while back—we had fewer ways to communicate change back then. Given all the fancy technologies in a modern laptop/mobile device, I wonder how much more we could tell the user without slowing down to give visual feedback—instead communicating by haptic and/or 3D-audio feedback after the fact (the same way that e.g. macOS plays a sound effect after-the-fact when you put something in the Trash—but with a procedurally-synthesized soundscape, rather than the static "it went to the bottom-right.")
  - bonestormii_ 6y ago
    Oooo. So I think this is a terrible idea for most people, but something I would personally love. I'm a big fan of 3 monitors in a slight "wrapping" formation, but there are times when some event occurs on a screen which is literally behind me if I'm looking at one of the far monitors. It would be so cool to have 3D audio feedback that lets you calibrate to the layout of your monitors.
- cellularmitosis 6y ago
  > Programmers had to introduce intentional latency Hmm, perhaps if you replace the word "latency" with "duration"?
- joshspankit 6y ago
  Having seen all this from the inside of more offices than I can remember, I would say definitively yes. That programmers did have to introduce delays for that, and for other reasons. However, this was a trust thing, and not an innate limitation of human capacity. Now that we’re in 2020, I would argue that almost 0 users need that crutch. If the work is done, it’s done. Similarly, employees on early keyboard-only terminals didn’t need any delay either. They trusted that when they said do X, the system did it. How else could you process dozens (or hundreds!) of items a minute?
weinzierl 6y ago
I worked with an Indy for some time and what was really cool - besides the smooth and fast reaction to user input you mentioned - was that the UI elements were scalable. If I remember correctly they were vector and not bitmaps. Back then I thought that this will soon be the norm. I'd never imagined that we would still be struggling with this more than 20 years later. EDIT: After googling SGI workstation models I think what I used was actually most likely an O2[1]. Great design, I remembered its distinct look even after so many years. [1] https://en.wikipedia.org/wiki/SGI_O2 https://en.wikipedia.org/wiki/SGI_O2
derefr 6y ago
It certainly is. Most of the reason modern computers don't feel instantaneous is actually a trade-off: old computers were less adaptive to change. In old GUIs (e.g. Windows 3.1), many things—file associations, program launchers, etc.—got loaded from disk into memory once—usually at GUI startup—and then the state of those things was maintained entirely in memory, with programs that updated the on-disk state of those things either 1. also independently updating the in-memory state with a command sent to the relevant state-database-keeper; or 2. requiring that you log out and back in to see changes. Today, we don't have everything sitting around loaded into memory—but in exchange, we have soft-realtime canonicity, where the things you see in the GUI reflect the way things are, rather than a snapshot of the way things were plus (voluntary, possibly missable/skippable) updates. Install a program that has higher-than-default-binding file associations? The files in your file manager will update their icons and launch actions, without the program needing to do anything. There's ways to eat your cake and have it too—to have on-disk canonicity and instant updates—but this require a very finicky programming model†, so we haven't seen any GUI toolkit offer this, let alone one of the major OSes do so. † Essentially, you'd need to turn your Desktop Environment into a monolithic CQRS/ES aggregate, where programs change the DE's state by sending it commands, which it reacts to by changing in-memory state (the in-memory aggregate), and then persists a log of the events resulting from those commands as the canonical on-disk state (with other aggregates fed from those to build OLAPable indices / domain-state snapshots for fast reload.) This gets you "Smalltalk windowing semantics, but on a Unix filesystem substrate rather than a VM memory-image substrate."
- StillBored 6y ago
  While you might be slightly right, my experience tuning windows machines leads me to believe your missing the mark. I'm going to say the three largest contributions to general desktop lag are: Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up. Too many layers between the application draw commands and the actual display. All this compositing, vsync, and minimal 2d acceleration creates a low level persistent lag. Disabling aero on a win7 machine does wonders to its responsiveness. But even then pre-vista much of the win32 GDI/drawing API was basically implemented in hardware on the GPU. If you get an old 2d win32 API benchmark, you will notice that modern machines don't tend to fare well in raw API call performance. 30 seconds poking around on youtube, should find you a bunch of comparisons like this https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM&feature=emb_logo https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM.... Keep in mind that even in 2020 pretty much every application on the machine is still relying on GDI (same as linux apps relying on xlib). Input+processing lag, USB is polling with a fairly slow poll interval rate (think a hundred or so ms). Combined with the fact that the keystrokes/events then end up queued/scheduled through multiple subsystems before eventually finding their way to the correct window, and then having to again reschedule and get the application to retrieve and process it via GetMessage()/etc. Basically, this is more a function of modern software bloat, where all those layers of correct architecture add more overhead than the old school get the ps2 interrupt, post a message to the active window queue, schedule the process managing the window messages. (https://social.technet.microsoft.com/Forums/windows/en-US/b18330ea-ded6-48ae-a524-da065eafaef1/changing-usb-polling-rate-x64?forum=w7itprohardware https://social.technet.microsoft.com/Forums/windows/en-US/b1...) There are a number of other issues, but you can retune those three areas to some extent, and the results are a pretty noticeable improvement. Having someone at MS/etc go in and actually focus on fixing this might have a massive effect with little effort. But that doesn't appear to be in the cards, since they appear to be more interested in telemetry and personal assistants.
Lutzb 6y ago
Just yesterday I started a VM of beta2 of HaikuOS for a good dose of nostalgia. Some observations: the responsiveness of the UI is instantaneous. So much so that it feels alien nowadays. Also the UI does not waste space, but at the same time it does not feel cluttered. Laying out windows feels more organized than Windows 10 or recent macOS. I can't really point out why. Lastly, having dedicated window borders is so useful for aiming the mouse pointer when reszing. At some point our UIs became more a design than a utility.
- keithnoizu 6y ago
  I was really sad to see BeOS go the way of the dodo as a kid, was a great os.
cellularmitosis 6y ago
(straying slightly off-topic) I recently had the same experience with an Apple eMac. Grab a window, shake it around as fast as you can, or just move the mouse cursor around in circles quickly. "Whoa, why does this seem so much more responsive than my modern machines?" Two things, I think: 1) the mouse cursor is being updated with every vertical refresh (80Hz), and 2) the latency of the CRT must be lower than an LCD. Not bad for a 700MHz, 18 year old machine!
- blattimwind 6y ago
  CRTs are "dumb" devices, they literally just amplify the R/G/B analog signal while deflecting a beam using electromagnets according to some timing signals. As far as input lag goes, they're the baseline. For fast motion they have some advantages at leat over poor LCD screens as well, since non-strobing LCDs quite literally crossfade under constant backlight between the current image and the new image; we perceive this crossfading as additional blurring. A strobing LCD on the other hand shifts the new image into the pixel array and lets the pixels transition while the backlight is turned off. The obvious problem - it's flickering. LCDs that aren't optimized for low latency will generally just buffer a full frame before displaying it, coupled with a slow panel these will typically have 25-35 ms of input lag at 60 Hz. LCDs meant for gaming offer something called "immediate mode" or similar, where the controller buffers just a few lines or so, which makes the processing delay irrelevant (<1 ms). The image is effectively streamed through the LCD controller directly into the pixel array.
rayiner 6y ago
This is true even on more recent vintage stuff. Little stutters are far more common on my iPhone XR with iOS 13 than they were on my old 6S Plus, much less the iPhone 5.
jordache 6y ago
>holy crap the UI elements feel instantaneous. I seriously doubt it's an SGI optimization. I had an SGI Octane (multiple levels higher than an Indy). I've never felt IRIX's UI was noticeably more performant the contemporaneous Windows running on standard consumer PC hardware..
- tluyben2 6y ago
  Definitely felt like it to me; NT (4?) was sluggish. It was much better than the other Windows but at our office it was kind of a joke (no-one touched them unless they needed to compile to an .exe) compared to SGI / Sun machines.
  - jordache 6y ago
    I recall running NT on an Integraph workstation with 64MB of RAM.. Holy crap that was FAST!
- p_l 6y ago
  There was a certain level of optimization, though arguably the graphic stack was much more complex than GDI, so yes, Windows 9x with GDI accelerator would have more performant interface for basic work. Xsgi included some interesting optimizations, starting with how it was a compositing X server and a feature that is known to break GTK3 all the time - Xsgi would provide a low color visual as the first choice, and this was reflected in the provided Motif and other libraries and exploited by software developed for Irix - the latter mostly because you could not depend on the end user having a 24bit display, though. This means that the bandwidth requirements across all stages of drawing was reduced for common UI components, instead of slinging around high resolution 32bit RGBA bitmaps for everything as is the norm today on Linux. I haven't checked, but I strongly suspect that the more ascetic UI controls combined with classic X11 drawing calls also resulted in higher speed vs. slinging lots and lots of bitmaps with overdraw using XRender. For more on that, consider checking the literature written about avoiding overdraw on Android and how much of an impact it had on latency of user interface. iOS, btw, actually did a lot of dirty tricks to essentially prevent developers from doing any overdraw without explicitly going for it, and supposedly a strong part of early review process was checking for overdraw - because the actual iPhone hw was not that powerful and they ran close to the bandwidth budget per frame.
cameldrv 6y ago
The weird thing is that I remember the Indy being perceptually very slow at the time compared to Windows or Solaris. I just started using Linux part time on the desktop, and it’s significantly more responsive than MacOS, to the point that I prefer using it, even though the Linux UI otherwise stinks in a lot of ways.
nineteen999 6y ago
Back in 1998/1999 I worked in a mom-and-pop ISP shop with 64 dialup lines. We had an Indy that ran our mail server, website, databases, FTP and web hosting, LDAP server, etc etc. And it was still somewhat usable as a desktop as well.

walkingolof 6y ago

It would be interesting to measure this perceived performance with a camera to get hard numbers.

still_grokking 6y ago
https://danluu.com/input-lag/ https://danluu.com/input-lag/ https://news.ycombinator.com/item?id=16001407 https://news.ycombinator.com/item?id=16001407

whoopdedo 6y ago

There was a revelation a while back that instantaneous UX can be detrimental. If the action occurs so quickly that the users can't see it happening, they have a tendency to assume it didn't happen. Programmers had to introduce intentional latency through elements such as the file copy animation.

blattimwind 6y ago
I disagree. What you describe is a problem of interaction design founded on bad assumptions; with good interaction design I don't have to show the user that the computer is doing something for the user to be able to tell it happened. This is a problem of the system not showing its state transparently and relying on the user to notice a change in hidden state indicated by a transient window. Windows Explorer gets your particular example right: When you copy a bunch of files into a folder, it will highlight all of the copied files after it is done, so it doesn't matter if you saw the progress bar or not.
derefr 6y ago
That was indeed a while back—we had fewer ways to communicate change back then. Given all the fancy technologies in a modern laptop/mobile device, I wonder how much more we could tell the user without slowing down to give visual feedback—instead communicating by haptic and/or 3D-audio feedback after the fact (the same way that e.g. macOS plays a sound effect after-the-fact when you put something in the Trash—but with a procedurally-synthesized soundscape, rather than the static "it went to the bottom-right.")
- bonestormii_ 6y ago
  Oooo. So I think this is a terrible idea for most people, but something I would personally love. I'm a big fan of 3 monitors in a slight "wrapping" formation, but there are times when some event occurs on a screen which is literally behind me if I'm looking at one of the far monitors. It would be so cool to have 3D audio feedback that lets you calibrate to the layout of your monitors.
cellularmitosis 6y ago
> Programmers had to introduce intentional latency Hmm, perhaps if you replace the word "latency" with "duration"?
joshspankit 6y ago
Having seen all this from the inside of more offices than I can remember, I would say definitively yes. That programmers did have to introduce delays for that, and for other reasons. However, this was a trust thing, and not an innate limitation of human capacity. Now that we’re in 2020, I would argue that almost 0 users need that crutch. If the work is done, it’s done. Similarly, employees on early keyboard-only terminals didn’t need any delay either. They trusted that when they said do X, the system did it. How else could you process dozens (or hundreds!) of items a minute?

weinzierl 6y ago

I worked with an Indy for some time and what was really cool - besides the smooth and fast reaction to user input you mentioned - was that the UI elements were scalable. If I remember correctly they were vector and not bitmaps. Back then I thought that this will soon be the norm. I'd never imagined that we would still be struggling with this more than 20 years later. EDIT: After googling SGI workstation models I think what I used was actually most likely an O2[1]. Great design, I remembered its distinct look even after so many years. [1] https://en.wikipedia.org/wiki/SGI_O2 https://en.wikipedia.org/wiki/SGI_O2

derefr 6y ago

It certainly is. Most of the reason modern computers don't feel instantaneous is actually a trade-off: old computers were less adaptive to change. In old GUIs (e.g. Windows 3.1), many things—file associations, program launchers, etc.—got loaded from disk into memory once—usually at GUI startup—and then the state of those things was maintained entirely in memory, with programs that updated the on-disk state of those things either 1. also independently updating the in-memory state with a command sent to the relevant state-database-keeper; or 2. requiring that you log out and back in to see changes. Today, we don't have everything sitting around loaded into memory—but in exchange, we have soft-realtime canonicity, where the things you see in the GUI reflect the way things are, rather than a snapshot of the way things were plus (voluntary, possibly missable/skippable) updates. Install a program that has higher-than-default-binding file associations? The files in your file manager will update their icons and launch actions, without the program needing to do anything. There's ways to eat your cake and have it too—to have on-disk canonicity and instant updates—but this require a very finicky programming model†, so we haven't seen any GUI toolkit offer this, let alone one of the major OSes do so. † Essentially, you'd need to turn your Desktop Environment into a monolithic CQRS/ES aggregate, where programs change the DE's state by sending it commands, which it reacts to by changing in-memory state (the in-memory aggregate), and then persists a log of the events resulting from those commands as the canonical on-disk state (with other aggregates fed from those to build OLAPable indices / domain-state snapshots for fast reload.) This gets you "Smalltalk windowing semantics, but on a Unix filesystem substrate rather than a VM memory-image substrate."

StillBored 6y ago
While you might be slightly right, my experience tuning windows machines leads me to believe your missing the mark. I'm going to say the three largest contributions to general desktop lag are: Animations and intentional delays. It can't be said, how much faster a machine feels when something like MenuShowDelay is decreased to 0, or the piles of animations are sped up. Too many layers between the application draw commands and the actual display. All this compositing, vsync, and minimal 2d acceleration creates a low level persistent lag. Disabling aero on a win7 machine does wonders to its responsiveness. But even then pre-vista much of the win32 GDI/drawing API was basically implemented in hardware on the GPU. If you get an old 2d win32 API benchmark, you will notice that modern machines don't tend to fare well in raw API call performance. 30 seconds poking around on youtube, should find you a bunch of comparisons like this https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM&feature=emb_logo https://www.youtube.com/watch?time_continue=25&v=ay-gqx18UTM.... Keep in mind that even in 2020 pretty much every application on the machine is still relying on GDI (same as linux apps relying on xlib). Input+processing lag, USB is polling with a fairly slow poll interval rate (think a hundred or so ms). Combined with the fact that the keystrokes/events then end up queued/scheduled through multiple subsystems before eventually finding their way to the correct window, and then having to again reschedule and get the application to retrieve and process it via GetMessage()/etc. Basically, this is more a function of modern software bloat, where all those layers of correct architecture add more overhead than the old school get the ps2 interrupt, post a message to the active window queue, schedule the process managing the window messages. (https://social.technet.microsoft.com/Forums/windows/en-US/b18330ea-ded6-48ae-a524-da065eafaef1/changing-usb-polling-rate-x64?forum=w7itprohardware https://social.technet.microsoft.com/Forums/windows/en-US/b1...) There are a number of other issues, but you can retune those three areas to some extent, and the results are a pretty noticeable improvement. Having someone at MS/etc go in and actually focus on fixing this might have a massive effect with little effort. But that doesn't appear to be in the cards, since they appear to be more interested in telemetry and personal assistants.

Lutzb 6y ago

Just yesterday I started a VM of beta2 of HaikuOS for a good dose of nostalgia. Some observations: the responsiveness of the UI is instantaneous. So much so that it feels alien nowadays. Also the UI does not waste space, but at the same time it does not feel cluttered. Laying out windows feels more organized than Windows 10 or recent macOS. I can't really point out why. Lastly, having dedicated window borders is so useful for aiming the mouse pointer when reszing. At some point our UIs became more a design than a utility.

keithnoizu 6y ago
I was really sad to see BeOS go the way of the dodo as a kid, was a great os.

cellularmitosis 6y ago

(straying slightly off-topic) I recently had the same experience with an Apple eMac. Grab a window, shake it around as fast as you can, or just move the mouse cursor around in circles quickly. "Whoa, why does this seem so much more responsive than my modern machines?" Two things, I think: 1) the mouse cursor is being updated with every vertical refresh (80Hz), and 2) the latency of the CRT must be lower than an LCD. Not bad for a 700MHz, 18 year old machine!

blattimwind 6y ago
CRTs are "dumb" devices, they literally just amplify the R/G/B analog signal while deflecting a beam using electromagnets according to some timing signals. As far as input lag goes, they're the baseline. For fast motion they have some advantages at leat over poor LCD screens as well, since non-strobing LCDs quite literally crossfade under constant backlight between the current image and the new image; we perceive this crossfading as additional blurring. A strobing LCD on the other hand shifts the new image into the pixel array and lets the pixels transition while the backlight is turned off. The obvious problem - it's flickering. LCDs that aren't optimized for low latency will generally just buffer a full frame before displaying it, coupled with a slow panel these will typically have 25-35 ms of input lag at 60 Hz. LCDs meant for gaming offer something called "immediate mode" or similar, where the controller buffers just a few lines or so, which makes the processing delay irrelevant (<1 ms). The image is effectively streamed through the LCD controller directly into the pixel array.

rayiner 6y ago

This is true even on more recent vintage stuff. Little stutters are far more common on my iPhone XR with iOS 13 than they were on my old 6S Plus, much less the iPhone 5.

jordache 6y ago

>holy crap the UI elements feel instantaneous. I seriously doubt it's an SGI optimization. I had an SGI Octane (multiple levels higher than an Indy). I've never felt IRIX's UI was noticeably more performant the contemporaneous Windows running on standard consumer PC hardware..

tluyben2 6y ago
Definitely felt like it to me; NT (4?) was sluggish. It was much better than the other Windows but at our office it was kind of a joke (no-one touched them unless they needed to compile to an .exe) compared to SGI / Sun machines.
- jordache 6y ago
  I recall running NT on an Integraph workstation with 64MB of RAM.. Holy crap that was FAST!
p_l 6y ago
There was a certain level of optimization, though arguably the graphic stack was much more complex than GDI, so yes, Windows 9x with GDI accelerator would have more performant interface for basic work. Xsgi included some interesting optimizations, starting with how it was a compositing X server and a feature that is known to break GTK3 all the time - Xsgi would provide a low color visual as the first choice, and this was reflected in the provided Motif and other libraries and exploited by software developed for Irix - the latter mostly because you could not depend on the end user having a 24bit display, though. This means that the bandwidth requirements across all stages of drawing was reduced for common UI components, instead of slinging around high resolution 32bit RGBA bitmaps for everything as is the norm today on Linux. I haven't checked, but I strongly suspect that the more ascetic UI controls combined with classic X11 drawing calls also resulted in higher speed vs. slinging lots and lots of bitmaps with overdraw using XRender. For more on that, consider checking the literature written about avoiding overdraw on Android and how much of an impact it had on latency of user interface. iOS, btw, actually did a lot of dirty tricks to essentially prevent developers from doing any overdraw without explicitly going for it, and supposedly a strong part of early review process was checking for overdraw - because the actual iPhone hw was not that powerful and they ran close to the bandwidth budget per frame.

cameldrv 6y ago

The weird thing is that I remember the Indy being perceptually very slow at the time compared to Windows or Solaris. I just started using Linux part time on the desktop, and it’s significantly more responsive than MacOS, to the point that I prefer using it, even though the Linux UI otherwise stinks in a lot of ways.

nineteen999 6y ago

Back in 1998/1999 I worked in a mom-and-pop ISP shop with 64 dialup lines. We had an Indy that ran our mail server, website, databases, FTP and web hosting, LDAP server, etc etc. And it was still somewhat usable as a desktop as well.