Hacker News Reader

Comment by callalex | Hacker News Reader

Doesn’t a heavy drop shadow solve the window border problem? Although these days those seem to be fading or disappearing as well.

View on HN

I'm sure it's negligible these days, but there's also the concern of an increased graphics load since you'll have to do an extra pass for the transparency. But I don't want to dive too far into the mindset of "everything must be optimized to the max".

My 0.3GHz iMac in 1996 could draw and resize window drop shadows at 60fps while simultaneously encoding an MP3 without a hitch. It’s seriously inexpensive computationally.

What OS do you think you were running in 1996?

Sorry, it was 1998. I’m pretty sure Mac OS 8 had drop shadows but even if it didn’t, I took that machine all the way to 10.4 and every version of OS X had drop shadows.

Classic Mac OS drop shadows were opaque, hence a lot cheaper.

I don't think OS X is a good example of your point because resizing windows was incredibly sluggish for a long time. I always figured it was somehow due to the combination of live resizing plus ubiquitous compositing, but I never understood why it was so slow.

Resizing is slow because it is a back-and-force between the compositor (insanely fast, no bottleneck here) and a given user application, which receives a resize event multiple times a second, has to relayout its UI (CPU-bound - OS X might have had a phase when it had to run a constraint solver), and then rerender every widget in the new size. Shadows don’t matter here at all.

There were live resizing hacks on classic MacOS that often worked pretty well, depending on the app. So it seemed pretty shocking to me how huge the regression was in the early days of OS X.

I don’t think the graphics hardware was always “insanely fast” back in those days, but even so, there must have been some terrible bottlenecks in the software.

As a user there was no way around it, and if I recall right, even as a developer it was hard to get decent resizing performance out of the system widgets.

One of the very few times I can recall where Apple has shipped something with such poor performance. Maybe most people didn’t notice or didn’t care because they just don’t resize windows very often?

Yep OS X wasnt til 2000/2001 and absolutely NOT smooth even on relatively new high end Macs at the time.

OS 8 and 9 were winXP like in terms of desktop effects - no soft anything.

Ehhhh it's really not that intensive.

Computers are very fast. GPUs are way faster than you think. Of course, it doesn't feel like that way since all the abstractions and layers kill performance by a thousand cuts.

Remember, "Aero" was a thing almost 20 years ago and that was a graphically intensive window renderer at that time. Nowadays we could have 50x better effects without a problem but UI designers are not willing to.

Oh for sure, I'm with you. Old graphics work has this mindset of avoiding transparency passes stuck in my head. Certainly a small part of the bigger problem.

Not when the windows are dark.

I used to have that problem when using xterm: white text on black background. I worked around it by writing a script that gave each new xterm instance a different dark background colour. Each window by its own felt like it was still black but when you put two next to each other you'd notice the difference in hue.

Then I switched to mate-terminal which put a nice big scrollbar in the right-side border of each window, so I didn't need that script any more.

Yes

Reply on news.ycombinator.com