Mabye too much CPU usage to redraw the screen yet enough to operate the mouse.

The application hanged, therefore it was not drawing itself on the screen anymore. The picture it takes up was not re-drawn in the framebuffer (since it is hanged and not sending any picture to be drawn on the screen).

The picture in front however still sends a picture to be drawn into the framebuffer.

So you have a situation where you have a piece of empty space, which is ONLY drawn into when something appears in front of it. the space is not updated (ie. deleted) at each frame, so the old image stays in place, and the window in front will get drawn into it a second time. As you move the front image, it'll change position, and will get drawn at differnt positions.

I don't know how else to explain it in a simpler way, you have to be familiar with framebuffer rasterizers to understand it.

>>54652645
Since Windows Vista, Windows uses a compositing Window Manager. Before, it was a stacking one, which created your pic related effect when a program crashed.

>>54652773
>>54652775
I actually understand. I don't have programming experience related to that subject but I understand what a framebuffer is.

Thanks.

because windows can't into desktop refresh GDI calls fast enough

>>54652773
That's basically it.

Windows GDI doesn't redraw your window for you - it sends an event to your event thread, asking your application to redraw itself.

If your event thread hangs (for example because your application only runs one thread and that is the event thread - in which case, you're an idiot - or the entire application has been suspended because it's just basically segfaulted), it won't receive that event. So when GDI asks it to redraw, nobody's home. No redraws.

The exact same thing can happen in the X Window System, or GEM, NeXT, oldschool MacOS, or in fact any GUI that uses a dumb window manager. BeOS is immune I think, but BeOS ran on black magic.

>>54652775
Expanding: Vista optionally uses the DWM (Desktop Window Manager), a compositing UI renderer. The old one is still available (was removed in Windows 8, I think).

That gives every application their own framebuffer to do redraws to (which is how it can do thumbnails, etc) on a redraw call - which uses a little more memory GPU-side (this is why GUIs didn't used to be done this way - back when screen memory was actually a really big chunk of your RAM!), but because the window manager is doing the blitting/compositing from the application framebuffer to the actual (potentially double/triple-buffered) screen itself, it allows for GPU-accelerated window compositing.

That's also how it handles the "glass" effects. Windows 8/8.1/10 does the same thing, but doesn't have to do as much alpha-blending because of the more "flat" UI; but there are in fact still a few very subtle shadows and stuff.

The exact same technique is used in, for example, Compiz, or Weston.

An application might still hang its event thread, but if it does it just won't update its framebuffer anymore. There's a watchdog timer on that (the window fades out).

>>54652645
Something happened.

>>54654035
Go away Bill Gates. Nobody likes your jokes