The thing (screenshot and all) was routine done in the 90s with all those fancy non-rectangular applications/demos/launchers [usually available on CDs that came w/ magazines]. They had transparent/alpha zones that copied the screen under them.

Ahh so THAT's how they did that!

It depends. Windows can be set to shapes going back to like Windows 95, iirc.

But alpha, specifically, would be faked at that point. Windows 2000 supported alpha for such things in a basic way, like XP. Vista with Aero and 7 then really expanded the themes and the window compositing.

Back in the day terminals under Linux did that to fake transparency: they just copied a chunk of the root window (where you put some wallpaper) as the terminal background and applied an alpha layer if the user wanted a translucid color.

Fake transparency is still a thing, for desktops without compositor. Not only in terminals, but also in docks.

But docks work in a different way, such as XRender or just a PNG with an alpha layer. Much less expensive than copying a chunk of the backdrop and then "pasted" at your terminal background.

Often docks will be able to show you the underlying windows behind it, even without compositing. But under the terminal with fake transparency you couldn't see another window behind it, just the backdrop part.

I think X11 had some extensions to allow translucency too for software like oneko, xroach or such.

From my experience this is wrong. If you set a transparent background in wxwidgets/gtk it will show you a grey background. And gtk3 even removed the ability to query the x background pixmap. So if there is better support for this at an X level, this is not available above.

See https://github.com/onli/simdock/issues/11, and if there really are good alternative solutions I'd be happy for some help.

Ah, too bad then. So, lots of stuff got deprecated, I didn't notice that until right now.

Still, there was another tech not querying the background pixmaps, but used from old X11 software to do non-rectangular windows. Oclock, maybe.

Why is it less expensive? Sounds like the exact same operation, except the OS is doing it.

No. XRender worked in a different way than ATerm/Eterm.

Maybe some incompetent people did it that way, but 1-bit transparency was very well possible with native Windows APIs in the 90s (see SetWindowRgn). Later on (starting with Windows 2000 IIRC) it was also possible to have semi-transparent (alpha-blended) regions.

It's not stupid if it works...

Please educate yourself before you accuse people of incompetency. Of course it was about (pseudo) alpha blending because "smooth shadows" around everything became very popular in the late 90s.

In a thread about “if it’s not stupid if it works” you accuse people of doing something “incompetent” by doing something ostensibly “stupid but works” but totally miss on what was even possible “non-stupidly.” There feels like some form of irony here.

Yes, obviously there a grain of irony in the reply. ;)

I'm not convinced it works though. A screenshot would break any animations playing underneath

Not exactly. With 2000/XP you can set the entire window opacity. Still no gdi+ native. So regions were still just shapes(1bit mask). Trying to set a pre-multiplied bitmap to a window will just give you a brightened version(the multiplied version).

Though there was some support for cursor shadow at this point, and the improved GDI heap really helped, making faking a window drop shadow actually pretty feasible. Vista and Aero is the first native support for Windows with alpha channels.

I actually liked Vista. It worked just fine and wasn't unnecessarily reorganized. Plus the improvements to the OS threading model were excellent, which is why 7 is so incredibly rock solid, probably peak Windows.

That's called double-buffering.

They invented double-buffering! :)

I think it was meant as a joke, so for anyone else reading it, no it is not actually double-buffering.

Half a joke, because the concept is very much the same. You "paint" to an invisible buffer and then you swap.

Yeah, but the concept of double buffering is to swap every frame, for performance gains.

Here nothing gets swapped, and just temporary the screen gets hidden. So vaguely similar ... but not very much the same in my opinion.

freeze-frame buffering

Performance gains is kinda iffy. You actively hurt latency for the sake of consistency. Even more with triple buffering.

double-bluffering?

You could just overlay the Outlook window.

Love it, lol

I absolutely love this.

Early versions of iOS did this too. You’d tap an app icon and the app would appear instantly in its prior state … but it was just a saved screenshot that iOS displayed while the app was actually loading.

Really it still does, in a way. The ”apps” in the app switcher work that way. Even if the app is still live in memory, it’s not rendering to the switcher all the time. And if it was killed, then the pic is all that’s left.

While this is a great hack, this feels like a terrible product to sell to customers. I work on a game with an SDK for plugin development, but sometimes third party developers go off and want to do things that the SDK doesn't offer. Since they get to be in our address space, it's pretty trivial to snoop around internal resources if you really wanted to. The problem is, when we update some core parts of the engine, we tend to break these things. Then users get upset with us and the third parties start to complain that we broke their hacks. It's just a bad experience for everyone.

Out of sheer curiosity, could you name this game?

Sure, it’s X-Plane 12. But this really is a problem for any software that is continuously being developed and that sees active releases. Any time the internal API or ABI breaks, chances are you break someone’s work with it.

Thanks for sharing, again - I was just curious. That's a fair statement indeed :)