3 ms·

>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 nev

>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.

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.