[kaba0]

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.

[iainmerrick]

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?