3 ms·

I liked how everything seemed intentionally rectangular. Perhaps made it easier to organize things mentally. It was also nice having full menus at the top of

I liked how everything seemed intentionally rectangular. Perhaps made it easier to organize things mentally. It was also nice having full menus at the top of windows.

acdha 6y ago
There was also a big technical reason for that: graphics subsystems sucked back then. Hardware acceleration ranged from non-existent to primitive and RAM was tight. If you have two objects (window, control, etc.) displayed and they're rectangular, you can update one of them without needing to involve the other one at all. Since your entire display was a single buffer in memory, each application would draw directly in its chunk of memory. When you did something which made things move you could use simple array math to move the previously-painted block of memory to the new location or, if you had a really fancy graphics card, call a BitBlt operation which would move x1,y2-x2,y2 to the new location. Then you had to tell whatever was now visible in the source location to repaint that region. Adding things like transparency or rounded corners breaks a lot of that — you need to know what's underneath to update the display — and that wasn't fast enough to use until you had enough RAM to store each object independently so you don't need to ask each application to repaint as things move around. Compositing window managers started early — I believe the Amiga had that — but the first mainstream OS was when Mac OS X shipped Quartz and it had performance drawbacks (i.e. tolerable but not great window dragging performance) until they shipped Quartz Extreme which used OpenGL to do the hard work. Microsoft caught up about 5 years later with Windows Vista, in part because they had more users to support with inadequate hardware.
- Guest42 6y ago
  Thank you, I have had zero exposure to what goes on in those areas.
- wruza 6y ago
  Apps could draw directly to DC, but it flickered a lot, and everyone quickly ended up with CreateCompatible{Bitmap,DC} and blitting into BeginPaint’s DC after drawing. After all, at win95 you had 4 to 8 megabytes or RAM - you definitely had the space. Not sure when it happened, but I can remember fighting with flicker circa 97. Also, rectangular controls were what you had in standard winapi, which was based on HWNDs, which were rectangular-only. I don’t think that unroundness was really forced by hardware constraints (transparency - yes), it was just a default simplest flavor of time. (And not that I like round/flat/text-only controls. What we called “flat” back then is pretty 3d-bordered in modern terms, and what we called “round”, today is border-radius:3px)
  - acdha 6y ago
    4-8MB wasn’t all that much if you were running more than one app at >640x480x256. It was certainly possible but fancy visual effects were going to exclude a lot of low-end hardware, which is what a LOT of mainstream users bought since hardware cost a good but more back then and the value proposition was less established. I agree that roundness wasn’t prohibitive in general. The rectangular nature of the APIs encouraged it but you certainly saw it in applications. What I was thinking about most was complex usage where there was overlap outside of the active context (e.g. dragging a window with the expectation of a lower layer showing around the curve, rather than either not having that or being able to assume a solid fill color) or interfering with hardware accelerated painting or later video decoding which only worked in rectangular regions.

I liked how everything seemed intentionally rectangular. Perhaps made it easier to organize things mentally. It was also nice having full menus at the top of windows.

acdha 6y ago

There was also a big technical reason for that: graphics subsystems sucked back then. Hardware acceleration ranged from non-existent to primitive and RAM was tight. If you have two objects (window, control, etc.) displayed and they're rectangular, you can update one of them without needing to involve the other one at all. Since your entire display was a single buffer in memory, each application would draw directly in its chunk of memory. When you did something which made things move you could use simple array math to move the previously-painted block of memory to the new location or, if you had a really fancy graphics card, call a BitBlt operation which would move x1,y2-x2,y2 to the new location. Then you had to tell whatever was now visible in the source location to repaint that region. Adding things like transparency or rounded corners breaks a lot of that — you need to know what's underneath to update the display — and that wasn't fast enough to use until you had enough RAM to store each object independently so you don't need to ask each application to repaint as things move around. Compositing window managers started early — I believe the Amiga had that — but the first mainstream OS was when Mac OS X shipped Quartz and it had performance drawbacks (i.e. tolerable but not great window dragging performance) until they shipped Quartz Extreme which used OpenGL to do the hard work. Microsoft caught up about 5 years later with Windows Vista, in part because they had more users to support with inadequate hardware.

Guest42 6y ago
Thank you, I have had zero exposure to what goes on in those areas.
wruza 6y ago
Apps could draw directly to DC, but it flickered a lot, and everyone quickly ended up with CreateCompatible{Bitmap,DC} and blitting into BeginPaint’s DC after drawing. After all, at win95 you had 4 to 8 megabytes or RAM - you definitely had the space. Not sure when it happened, but I can remember fighting with flicker circa 97. Also, rectangular controls were what you had in standard winapi, which was based on HWNDs, which were rectangular-only. I don’t think that unroundness was really forced by hardware constraints (transparency - yes), it was just a default simplest flavor of time. (And not that I like round/flat/text-only controls. What we called “flat” back then is pretty 3d-bordered in modern terms, and what we called “round”, today is border-radius:3px)
- acdha 6y ago
  4-8MB wasn’t all that much if you were running more than one app at >640x480x256. It was certainly possible but fancy visual effects were going to exclude a lot of low-end hardware, which is what a LOT of mainstream users bought since hardware cost a good but more back then and the value proposition was less established. I agree that roundness wasn’t prohibitive in general. The rectangular nature of the APIs encouraged it but you certainly saw it in applications. What I was thinking about most was complex usage where there was overlap outside of the active context (e.g. dragging a window with the expectation of a lower layer showing around the curve, rather than either not having that or being able to assume a solid fill color) or interfering with hardware accelerated painting or later video decoding which only worked in rectangular regions.