Our startup built a plugin for Microsoft Outlook. It was successful, and customers wanted the same thing but for Outlook Express. Unfortunately, OE had no plugin architecture. But Windows has Windows hooks and DLL injection. So we were able to build a macro-like system that clicked here and dragged there and did what we needed it to. The only problem was that you could see all the actions happening on the screen. It worked perfectly, but the flickering looked awful.
At lunch, someone joked that we just had to convince OE users not to look at the screen while our product did its thing. We all laughed, then paused. We looked around at each other and said "no, that can't work."
That afternoon someone coded up a routine to screenshot the entire desktop, display the screenshot full-screen, do our GUI manipulations, wait for the event loop to drain so that we knew OE had updated, and then kill the full-screen overlay. Since the overlay was a screenshot of the screen, it shouldn't have been noticable.
It totally worked. The flickering was gone. We shipped the OE version with the overlay hiding the GUI updates. Users loved the product.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Our startup built a plugin for Microsoft Outlook. It was successful, and customers wanted the same thing but for Outlook Express. Unfortunately, OE had no plugin architecture. But Windows has Windows hooks and DLL injection. So we were able to build a macro-like system that clicked here and dragged there and did what we needed it to. The only problem was that you could see all the actions happening on the screen. It worked perfectly, but the flickering looked awful.
At lunch, someone joked that we just had to convince OE users not to look at the screen while our product did its thing. We all laughed, then paused. We looked around at each other and said "no, that can't work."
That afternoon someone coded up a routine to screenshot the entire desktop, display the screenshot full-screen, do our GUI manipulations, wait for the event loop to drain so that we knew OE had updated, and then kill the full-screen overlay. Since the overlay was a screenshot of the screen, it shouldn't have been noticable.
It totally worked. The flickering was gone. We shipped the OE version with the overlay hiding the GUI updates. Users loved the product.