6 ms·

You’re right about 93, but if you go about five years later and keep all the animations turned on, it looked a lot like this. Those animations killed performanc

by hluska 7y ago

You’re right about 93, but if you go about five years later and keep all the animations turned on, it looked a lot like this. Those animations killed performance so I suspect that most people on here turned them off as quickly as I did, but this is a pretty good reproduction. It’s good enough that as I poke around, I remember specific events from my relative youth...

laumars 7y ago
Animated windows weren't a thing even in the late 90s. That required a compositing window manager. Linux was one of the first platforms to get them and Compiz wasn't even released until the mid 00s. Vista was the first MS operating system to properly support compositing (though XP -- and 2000 via undocumented APIs -- did support transparency effects). Animated icons have never existed aside from hacks like Active Desktop or active running programs in system tray / taskbar (again, using hacks where the icon was changed every second).
- int_19h 7y ago
  I'm pretty sure the API that changed the window transparency was documented in 2K, because I distinctly remember reading how to do it on MSDN after first seeing one of those in an app.
  - laumars 7y ago
    It was documented in Windows XP but I think it was Vista that really promoted the use of that effect ("Aero" was it?). Happy to be proved wrong about Windows 2000 but I don't recall seeing any documentation on MSDN back when I was playing around with Windows APIs. I remember I pinched the API guide for XP thinking "if it works in XP then it must work in Windows 2000" and the reason I remember that so vividly was because it didn't work properly. In fact it caused a kernel panic. Which was pretty much the only time I managed to upset Windows 2000 badly enough to cause a "blue screen of death".
    - int_19h 7y ago
      It definitely worked in 2K - there were many apps that implemented it as a bling feature as soon as it became known. The question is whether it was documented at the time. If you were able to build it for Win2K, and it compiled successfully, then it was supported - it wouldn't be in the headers otherwise. Even if you build it with XP as a target, and then run on 2K, you'd get a regular Win32 error about not being able to resolve a symbol from a DLL. Getting a BSOD indicates a driver issue. MSDN also says that it is supported for Win2K+: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setlayeredwindowattributes https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... Aero in Vista was something else - it was the first version of Windows that did whole desktop composition, and so it could do all kinds of fancy stuff, similar to Compiz that preceded it on Linux. Transparent windows in 2K/XP used per-window composition.
  - benibela 7y ago
    I think it worked in 2K
  - tracker1 7y ago
    It worked in 2k... used a customized litestep (iirc) theme with win2k for a long time. Definitely made use of the transparency bits.
    - laumars 7y ago
      Did that use Microsoft API though? It might have been possible to hack your own library to do the same thing as I'm pretty sure there were are Win32 APIs to read and write pixels outside of your form -- albeit performance almost certainly wouldn't be on a par doing it that way. (I say "pretty sure" because I once wrong a program to create a second mouse cursor but which was controlled via a game controller. The logic being I could multi-task my GUI operations. Obviously the logic was flawed and that application proved dumb but it was a fun development exercise none-the-less. Anyhow, I think I drew the cursor directly to screen by reading and writing pixels using some Win32 API; but I'm not super confident of that memory).
      - laumars 7y ago
        My comment is now too old to edit but another poster has provided some good insight https://news.ycombinator.com/item?id=22480864 https://news.ycombinator.com/item?id=22480864
      - tracker1 7y ago
        I'm not entirely sure... I know it worked in 2K, but didn't work for Win9x line, so I'm pretty sure it was in 2K/NT APIs, and not the 3.x/9x/me line. I don't think it was used by any of MS's internal themes until XP though.
- kstrauser 7y ago
  I had an Amiga with various hacks that animated windows. They don't require a compositing WM, although they're much easier to implement with one.
- II2II 7y ago
  There were things that people called animated windows and animated icons at the time, but the meaning was quite different from what we think about today. For example: an animated window was an animation effect on the frame when a window was opened or closed, while an animated icon could be showing one icon for a closed folder and another icon for an open folder. (These recollections are from 1995 era OS/2. Windows had it's own stuff going on, but I pretty much ignored it from the introduction of Windows 95 until late Windows XP.)
  - laumars 7y ago
    That's not what "Windows 93" (the site posted) is doing though. However I do take your point about the window borders, I had forgotten that was referred to as "window animations". I don't agree with your icon point though. I don't recall anyone calling those boolean icon states as "animated".
- anthk 7y ago
  You are wrong. Xrender could do half of the effects.
  - core-questions 7y ago
    Is this what Enlightenment used to achieve that?
    - anthk 7y ago
      Maybe. KDE menu transparencies used that. I think some terminals with true transparency used XRender, too.
  - laumars 7y ago
    Which bit is wrong? - Xrender wasn't released in the 90s, - isn't window manager (ie a compositing window manager could use Xrender for compositing (like KWin supports when OpenGL isn't available) but Xrender itself isn't a WM) - and isn't even available on Windows (which was the OS we were talking about) I think perhaps you might have misunderstood me? (it wasn't my clearest written post).
    - anthk 7y ago
      We are talking about how the composite extension for X was a must for FX, I said bullshit because I had these effects long before the X entension and Compiz. And I know XRender is not a WM, FFS, my first distro was Debian Woody so I know my shit better than those Compiz bling-bling new users. And not only KWIN did that, a lot of WM's did different FX in software by either using XRender or custom coding (such as Afterstep).
      - laumars 7y ago
        > We are talking about how the composite extension for X was a must for FX 1. No. I was talking about Windows. Compiz was mentioned as a comparison to give an idea of time lines. You then decided to interpret my entire post to mean something quite different. 2. The comment about compositing was window managers, not X. Xrender, in this context, would be equivalent to OpenGL (albeit one uses hardware frame buffers et al and the other uses software). 3. Even in your Xrender point, the window animations in Linux would still have to be done via a compositing window manager such as Kwin -- which supports both Xrander and OpenGL libraries. 3 (i). ...or if not a compositing WM, an entirely separate display manager replacing X. Though even there, you'd likely still want to go down the compositing route because it's much easier. > And I know XRender is not a WM, FFS, my first distro was Debian Woody so I know my shit better than those Compiz bling-bling new users. 1. Then why are you flipflopping between different stacks of libraries as if they're one and the same? 2. The length of time you've been using Linux isn't a useful yardstick for how much more you might know stuff 2 (i). Furthermore, HN is a technical crowd so I'm sure most on here have been using Linux at least that long. I've been running Slackware since the 90s and I know from previous conversations I'm far from a unique case. So I'd be careful about assuming your audience when commenting on here. 2 (ii). It's also worth noting that almost no new users would be using Compiz these days anyway. There's just no need when most of the popular desktop environments ship their own compositing WMs. Plus the novelty factor just isn't there now like it was back in 00s. 3. Also please tone down your language. There's no need to be rude. > And not only KWIN did that, a lot of WM's did different FX in software by either using XRender or custom coding (such as Afterstep). 1. Nobody said compositing had to happen in hardware. 2. "FX" like menu transparencies (as you mentioned elsewhere) isn't even remotely the same as the window animations originally being discussed and being demonstrated in the Windows 93 demo linked to; and for a multitude of reasons: 2 (i) For starters you're overlaying within the same window. Things used to get trickier when you needed "FX" to interact with parts outside of your form (worse still, other applications too). 2 (ii) Transparency also wasn't computationally expensive to do in software compared to the kind of transformations that Compiz did -- and that the Windows 93 demo does. The Compiz/93 style animations simply wouldn't have been practical for general purpose computing without hardware graphics libraries (bare in mind the specifications of the average computer in the 90s and early 00s). 2 (iii) ...and I know this from experience because I used to write graphical shells for both Windows and Linux in the late 90s and early 00s.

by hluska 7y ago

laumars 7y ago

Animated windows weren't a thing even in the late 90s. That required a compositing window manager. Linux was one of the first platforms to get them and Compiz wasn't even released until the mid 00s. Vista was the first MS operating system to properly support compositing (though XP -- and 2000 via undocumented APIs -- did support transparency effects). Animated icons have never existed aside from hacks like Active Desktop or active running programs in system tray / taskbar (again, using hacks where the icon was changed every second).

int_19h 7y ago
I'm pretty sure the API that changed the window transparency was documented in 2K, because I distinctly remember reading how to do it on MSDN after first seeing one of those in an app.
- laumars 7y ago
  It was documented in Windows XP but I think it was Vista that really promoted the use of that effect ("Aero" was it?). Happy to be proved wrong about Windows 2000 but I don't recall seeing any documentation on MSDN back when I was playing around with Windows APIs. I remember I pinched the API guide for XP thinking "if it works in XP then it must work in Windows 2000" and the reason I remember that so vividly was because it didn't work properly. In fact it caused a kernel panic. Which was pretty much the only time I managed to upset Windows 2000 badly enough to cause a "blue screen of death".
  - int_19h 7y ago
    It definitely worked in 2K - there were many apps that implemented it as a bling feature as soon as it became known. The question is whether it was documented at the time. If you were able to build it for Win2K, and it compiled successfully, then it was supported - it wouldn't be in the headers otherwise. Even if you build it with XP as a target, and then run on 2K, you'd get a regular Win32 error about not being able to resolve a symbol from a DLL. Getting a BSOD indicates a driver issue. MSDN also says that it is supported for Win2K+: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setlayeredwindowattributes https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... Aero in Vista was something else - it was the first version of Windows that did whole desktop composition, and so it could do all kinds of fancy stuff, similar to Compiz that preceded it on Linux. Transparent windows in 2K/XP used per-window composition.
- benibela 7y ago
  I think it worked in 2K
- tracker1 7y ago
  It worked in 2k... used a customized litestep (iirc) theme with win2k for a long time. Definitely made use of the transparency bits.
  - laumars 7y ago
    Did that use Microsoft API though? It might have been possible to hack your own library to do the same thing as I'm pretty sure there were are Win32 APIs to read and write pixels outside of your form -- albeit performance almost certainly wouldn't be on a par doing it that way. (I say "pretty sure" because I once wrong a program to create a second mouse cursor but which was controlled via a game controller. The logic being I could multi-task my GUI operations. Obviously the logic was flawed and that application proved dumb but it was a fun development exercise none-the-less. Anyhow, I think I drew the cursor directly to screen by reading and writing pixels using some Win32 API; but I'm not super confident of that memory).
    - laumars 7y ago
      My comment is now too old to edit but another poster has provided some good insight https://news.ycombinator.com/item?id=22480864 https://news.ycombinator.com/item?id=22480864
    - tracker1 7y ago
      I'm not entirely sure... I know it worked in 2K, but didn't work for Win9x line, so I'm pretty sure it was in 2K/NT APIs, and not the 3.x/9x/me line. I don't think it was used by any of MS's internal themes until XP though.
kstrauser 7y ago
I had an Amiga with various hacks that animated windows. They don't require a compositing WM, although they're much easier to implement with one.
II2II 7y ago
There were things that people called animated windows and animated icons at the time, but the meaning was quite different from what we think about today. For example: an animated window was an animation effect on the frame when a window was opened or closed, while an animated icon could be showing one icon for a closed folder and another icon for an open folder. (These recollections are from 1995 era OS/2. Windows had it's own stuff going on, but I pretty much ignored it from the introduction of Windows 95 until late Windows XP.)
- laumars 7y ago
  That's not what "Windows 93" (the site posted) is doing though. However I do take your point about the window borders, I had forgotten that was referred to as "window animations". I don't agree with your icon point though. I don't recall anyone calling those boolean icon states as "animated".
anthk 7y ago
You are wrong. Xrender could do half of the effects.
- core-questions 7y ago
  Is this what Enlightenment used to achieve that?
  - anthk 7y ago
    Maybe. KDE menu transparencies used that. I think some terminals with true transparency used XRender, too.
- laumars 7y ago
  Which bit is wrong? - Xrender wasn't released in the 90s, - isn't window manager (ie a compositing window manager could use Xrender for compositing (like KWin supports when OpenGL isn't available) but Xrender itself isn't a WM) - and isn't even available on Windows (which was the OS we were talking about) I think perhaps you might have misunderstood me? (it wasn't my clearest written post).
  - anthk 7y ago
    We are talking about how the composite extension for X was a must for FX, I said bullshit because I had these effects long before the X entension and Compiz. And I know XRender is not a WM, FFS, my first distro was Debian Woody so I know my shit better than those Compiz bling-bling new users. And not only KWIN did that, a lot of WM's did different FX in software by either using XRender or custom coding (such as Afterstep).
    - laumars 7y ago
      > We are talking about how the composite extension for X was a must for FX 1. No. I was talking about Windows. Compiz was mentioned as a comparison to give an idea of time lines. You then decided to interpret my entire post to mean something quite different. 2. The comment about compositing was window managers, not X. Xrender, in this context, would be equivalent to OpenGL (albeit one uses hardware frame buffers et al and the other uses software). 3. Even in your Xrender point, the window animations in Linux would still have to be done via a compositing window manager such as Kwin -- which supports both Xrander and OpenGL libraries. 3 (i). ...or if not a compositing WM, an entirely separate display manager replacing X. Though even there, you'd likely still want to go down the compositing route because it's much easier. > And I know XRender is not a WM, FFS, my first distro was Debian Woody so I know my shit better than those Compiz bling-bling new users. 1. Then why are you flipflopping between different stacks of libraries as if they're one and the same? 2. The length of time you've been using Linux isn't a useful yardstick for how much more you might know stuff 2 (i). Furthermore, HN is a technical crowd so I'm sure most on here have been using Linux at least that long. I've been running Slackware since the 90s and I know from previous conversations I'm far from a unique case. So I'd be careful about assuming your audience when commenting on here. 2 (ii). It's also worth noting that almost no new users would be using Compiz these days anyway. There's just no need when most of the popular desktop environments ship their own compositing WMs. Plus the novelty factor just isn't there now like it was back in 00s. 3. Also please tone down your language. There's no need to be rude. > And not only KWIN did that, a lot of WM's did different FX in software by either using XRender or custom coding (such as Afterstep). 1. Nobody said compositing had to happen in hardware. 2. "FX" like menu transparencies (as you mentioned elsewhere) isn't even remotely the same as the window animations originally being discussed and being demonstrated in the Windows 93 demo linked to; and for a multitude of reasons: 2 (i) For starters you're overlaying within the same window. Things used to get trickier when you needed "FX" to interact with parts outside of your form (worse still, other applications too). 2 (ii) Transparency also wasn't computationally expensive to do in software compared to the kind of transformations that Compiz did -- and that the Windows 93 demo does. The Compiz/93 style animations simply wouldn't have been practical for general purpose computing without hardware graphics libraries (bare in mind the specifications of the average computer in the 90s and early 00s). 2 (iii) ...and I know this from experience because I used to write graphical shells for both Windows and Linux in the late 90s and early 00s.