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...
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).
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.)
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".
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.
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".
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.
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.
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).
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.
- 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).
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).
> 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.
>wouldn't have been practical for general purpose computing without hardware graphics
Or just VESA and Windows' optimized 2D libraries. GDI is a good example. Most 2D FXs don't require a hard computation. Seriously, Enlightenment did those in software.
You underestimate what could've done in software in the 90's, especially when memory protection under w9x was nil and everything was much more low level.
Insecure? A lot. Would it work? Yes.
Windows 98 could do these with 3rd party software.
>Slackware in late 90's
Debian Woody was almost like late 90's for obvious reasons.
It shipped a 2.2 kernel with 2.4 being the optional and bleeding edge one.
> Or just VESA and Windows' optimized 2D libraries. GDI is a good example.
From what I remember of GDI (and admittedly it's been a while since I've done graphics development on Windows) GDI wasn't designed for real time animations. It was more designed for static (or at least semi-static) scenes like image editing. Real time transformations is a whole different ball game.
Either way, GDI certainly wasn't optimised. If you wanted optimised then you'd have used DirectDraw (which doesn't exist now but back then it was a thing).
> Most 2D FXs don't require a hard computation.
But we're not talking about "fx" as you keep calling it, we're talking about real time transformations interacting with multiple different canvases (to borrow a term from web development). Wobbly windows is a whole different ball game to transparent forms. Then you need to factor in that those transformations need to happen without slowing desktop performance.
Windows 9x used to do really basic "animations" which required no transformation effects and even that used to get turned off by a great many people on modest hardware because of the impact it had on performance.
You're just not being realistic about either the transformation effects in question (repeatedly moving the goal posts to basic translucency on stationary forms) nor the hardware of the era in question.
> Seriously, Enlightenment did those in software.
Enlightenment is a seriously cool piece of engineering but it didn't do compositing until E16. And it wasn't even the early versions of E16 either. So we're not talking late 90s / early 00s there either.
Also did Enlightenment really do that in software or are you just assuming it did?
> You underestimate what could've done in software in the 90's, especially when memory protection under w9x was nil and everything was much more low level.
Graphics development was not more low level. The opposite was actually the problem: Windows APIs lacked direct hardware access the early part of the 9x life time. In fact literally the entire point of GDI was to offer an approximation of what could be done with direct hardware access but without giving Windows developers low level APIs. The obvious side-effect of that is a massive performance hit. There was a reason DirectDraw was so sorely needed and a reason why a great many games developers still favoured DOS for the early part of 9x's life.
> Windows 98 could do these with 3rd party software.
But it didn't do real time transformation effects and that 3rd party software often ran like a sack of shit on peoples systems. Usually the people you saw who ran it well were gamers on high end systems.
> Debian Woody was almost like late 90's for obvious reasons.
No it wasn't. It was released in 2002[1]. The testing repo for woody wasn't even created until mid December 2000[2] (so basically 2001).
