Aero mini previews missing after a while...

The installation is done, and I see the same issue...

Aero is running, Flip3D operational, Aero peek is running... still keep on forgetting [the mini preview] after a while

No worries :)
Happy New Year to you too, Rich :)

I guess I'll have to wait if this issue is going to be resolved by Microsoft (maybe by the time SP1 comes out?)

And for now, I'm 99.9999% sure this is a tiny tiny tiny bug that is somewhat annoying, but I'm sure I can live with it :)

Well, I'm off to get some sleep then... (almost 7AM over here)

Cheers,

zzz2496

logicearth, it's not just explorer, it's anything that sits too long, it will loose the mini preview image.
Read my post where I put screenshots of my mini previews, you will see what I mean. Normally I can see the mini preview. It will disappear when I leave that app too long.

I only use Explorer as an example. Here's a way to invoke the bug, run an app, anything to your liking (say firefox), make it use the "Disable desktop composition" ticked. Now open any app (say windows media player classic, play a video), minimize it, make sure you can see the mini preview image (with video playing). Now start the app that you set compatibility (firefox), it will switch Aero OFF (DO NOT STOP media player classic from playing). Glance back at the mini preview of the minimized test app (media player classic), it will turn to "List View". Exit the compatibility enabled app (exit firefox), Aero will kick back in, glace back at the test app (media player classic), it will not show you the window state, instead you see an icon. I say this is a bug of whatever managing the windows instance, the Window Manager (DWM)

...Actually that is kind of misleading...the application does not actually handle that, DWM does. DWM flushed the data for the minimized window to make room for others, since the window is minimized it does not send updates to DWM....

See, the logic for a window's live preview/mini preview or whatever, should be associated with the window instance, so whatever the window looks like, the mini preview should show that image to you, whatever the state of the window (minimized or not), thus I call this a tiny tiny tiny annoying bug. :)

zzz2496

logicearth, I use it to make sure that the "bug" (window mini preview MIA) is invoked, just to speed things up... OR, you can just leave an explorer window minimized for an hour...

logicearth,

Ok, we are at different wave length here...

Here's my (so called) logic.

If DWM is trully a window manager, is should manage every single instance of a window, including it's "mini previews" or "thumbnails" or whatever we should call it. Like in MacOS, Aqua maintains the window state, a minimized window in MacOS will show in the dock, along with it's latest "view state". In Linux, the latest incarnation of KDE's window manager do the same thing (and compiz too), for whatever reason, if the behavior is when you hover to a "proxy" (in this case, a taskbar button), it will show the latest visual view of the window.

Now, if I stand by that logic, the mini previews are NOT gimmick, it's a visual representation of the window's content graphically, in many ways must show whatever the reason might happen to your DWM, it should still show. In Windows 7's case, it doesn't do that, the behavior is different... as your words, and I quote:

...All of the minimized windows are then removed until they are un-minimized. Now, unless an application is programmed to do so, it does not repaint itself when minimized...

This is a BUG, a window manager that doesn't show the content of it's "child object" that it's managing is bugged, it doesn't do the way it should do. Why do I say it's bugged, an app when you start it will create a window object, and registers it to the DWM so that DWM can draw it to the screen. Now, once it registers, it will keep on doing what it does... changing it's content, etc... It's up to the DWM process to maintain the visual presentation of the window it's managing, which in facts, it forgotten if the "buffers" are flushed...

My point is, this behavior is inconsistent, the inconsistency is the bug. If a Desktop Window Manager truly manages windows that are shown in our desktop, it should do just that consistently, for whatever reason the buffers are flushed or anything, it should "repaint" in the background without us asking it, it's the manager, it is its duty to do that, not us. This is just like "Windows Search" for desktop clients all over again, tacked on without reasonable logic... *sigh* (this is for another thread...)

zzz2496