I also have the problem with DF 5.1.1 sometimes freezing windows 7. The system hasn't technically crashed because it is still minimally responsive, e.g., I can close an open window but after clicking "Close" button it takes 2-3 minutes to respond. During this time one of the 4 cores is pegged at 100% utilization while the others are nominal, but the the core being used slowly changes if I try to interact with the system. (Mouse and system clock remain responsive.)

I have a 3-monitor system with the screen saver active only on the middle (#1) monitor, the other two blank. Per another post I have verified that the "Use Preview" mode is checked (although grayed out for #2 and #3). After 5min the monitors power off so I don't know the system is frozen until I try to interact with it.

Last week I was upgrading an HD to a larger one and the several hour long cloning process couldn't complete with DF running. I tried killing the DisplayFusion.exe program in task manager but that wasn't enough; I had to also kill DisplayFusionService.exe. (I had to do this right after bootup, otherwise I couldn't kill the process.) Simply disabling the screen saver didn't work.

I do have a second question about the wallpaper changing algorithm because it's not truly random and seems to use some subdirectories more often than others, meaning some pics show up much more frequently (>10k jpgs). But this is a secondary concern, the system freezes issues is much more important.

Thx.

Okay, I disabled DisplayFusionService from running. And I re-enabled DisplayFusion to manage the screen saver. I'll watch it over the next week or so and update this thread with what happens.

As to the wallpaper, I have noticed that when I add files they show up in the rotation not very long after (which is good). With the randomness, what I'm getting at is that pictures show up in clusters. For example, I have files named Butterfly001 to Butterfly100, Mountains001 to Mountains100, plus other files in the same directory and other directories. If Butterfly025 shows up, the next several will more likely than not also be Butterflyxxx, not Mountains or anything else. In other words, "nearby" filenames seem to have a preferential weighting relative to "far away" filenames, not each time picking a random file between 1 and 10,000. Again though, this is a secondary issue, but thanks for responding to it.

Okay, have an update.

Per previous discussion I had disabled DisplayFusionService and re-enable DF to manage screen saver. It worked fine for several days until I ran Windows Home Server 2011 to perform a backup. Part way through the backup Windows froze. It was an about 80 percent freeze as I could still close programs (albeit, very very slow response time). I tried this several times with the same result. When I exited DF entirely, the backup completed successfully. This compares to previously when I had DFS running and the freeze was about 95 percent (could move mouse, sometimes close a program, but not too much more).

What the freezes have in common was a program running that had intensive disk activity. The first freezings that prompted me to write were because I was using Acronis Disk Director to clone an HDD, and this time running WHS to backup my computer. The HDD clone was for a secondary HDD that DF did not access. This may or may not eliminate some kind of file access deadlock as the problem because when the system freezes, wallpaper changes also stop (but can't determine if that is due to the freezing or something else).

Intense disk activity is the common thread. Is DF locking a drive or using too high permissions that don't release quick enough with intense disk activity? With regular disk loads this wouldn't be a problem because disk access is rarely sustained for prolonged periods.

Don't know if this matters, but my system drive is an SSD, with a WD Velociraptor data drive, plus several secondary storage drives, all on MB SATA ports. And I had DF set to change the screen saver image every 30 seconds before turning off the display after 5 minutes. All image files that DF uses are on the WD data drive.

Hope this helps narrow things down.

This happens only when the DF screen saver is running. Otherwise I used the Windows built-in screen saver "Blank" and had no problems with Acronis Disk Director or WHS2011. I've never really used the others in Windows except to see what they look like.

When I disable DF from managing the screen saver (uncheck the box), it sets the Windows screen saver to "None". I then change this to "Blank" directly from Windows, not via DF.

The only screen saver setting I have used within DF is the "DisplayFusion Photos Screen Saver", with DF checked to manage the screen saver.

So it's a binary choice: Windows-Blank, or DF-Photos. System freezes only happen with DF-Photos.

Okay, I'll run a backup in the next couple of days with either Mystify or Ribbons as the screen saver selected through DF. I'll update this thread with the results.

Okay. What I did was select DF to manage the screen saver, and chose the Windows screen saver Mystify, with a 5 minute wait time. Rebooted. Ran a backup using WHS2011 and had no problems with system hangs or freezes. Two days later, with DF still managing the screen saver, ran another backup and had no problems.

So that would suggest that it's the Photos screen saver in DF that is the culprit.

Here's another funny problem I discovered. When DF manages the Mystify screen saver, moving my finger across the touchpad surface does not stop the screen saver and return my regular display; instead I have to tap the touchpad. When Windows manages the Mystify screen saver, a tap is not required, a simple movement across the touchpad surface will bring back the display.

Hope this helps.

Yes, the photos did display correctly until the system started freezing. The main directory has ~2600 jpg files/photos, with two subdirectories containing ~1300 and ~3300 jpg files/photos.

To put this in perspective, the screen saver displayed photos only on the center (primary) monitor of a 3-monitor system. The wallpaper displays photos only on the left and right monitors. Each monitor is assigned a separate directory to display photos from. The left has zero photos in the main directory and ~14,000 jpg/photos in ~180 subdirectories. The right has ~9500 photos in the main directory and no subdirectories. I don't know if this qualifies as "a large amount of images" though.

It may be a week before I have time to do this. I'll create a directory with 5 images in it and test the screen saver using that one.

Also, re the wallpaper and random selection, the directory that has all the image files in it directly (no subdirs), some images are displayed I estimate at least 10:1 more often than others. Whatever the algorithm is doing, it's not random and it's not shufffling; there is some type of bias in it. The other monitor with all the images in subdirectories seems to be better in this regard.

Finally had a chance to do the follow-up backup test. I created a new directory and put five (5) image files in it, set DF to manage the screen saver, selected the DF photos screen saver and directed it to use this new directory, changing photos every 30 seconds. Rebooted. Then ran a backup using WHS2011 and let it run. The screen saver kicked in five minutes later and the monitors powered off after ten minutes. About 45 minutes later I dragged my finger across the touchpad so the monitors would turn back on, then left it alone again. The backup later finished without event and the main computer (running DF) was still up and running.

Previously using the directory with a large number of images in it, it never made it to the 45 minute mark, typically locking up 15-30 minutes after starting the backup.

I'm sort of curious how the number of images in the directory can cause this kind of problem.

Just noticed that you released v6.beta4. Were either of the two issues we discussed fixed in this?

Just an update: I installed v6 beta5 because the changelog showed you had made some changes to the duplicate image problem. And from what I could tell running it for about four days, it seems like you've got the problem pretty well solved.

Noticed v6 beta6 yesterday, installed it. Still okay. But today I noticed a new problem. The DisplayFusion.exe process is using 25 percent of the CPU. (It may have been yesterday too but I just didn't notice it. I have a CPU gadget on my desktop.) I tried killing all four DF processes in Task Manager, restarted DF, but no joy. Uninstalled beta6, rebooted, reinstall beta5, still have 25 percent CPU utilization. But it's different. In beta5 it takes one of the cores (core 0 or 1 depending on how you count, of a quad core) to 100 percent, with beta6 the load is spread across the four cores.

This happened once or twice in the prior week using beta5, but I just killed DF.exe and restarted the program and all was well. This time nothing worked. I tried killing just the DFservice process, didn't help. Went back and forth between beta5 and beta6, rebooting between uninstalls and reinstalls, still 25 percent CPU utilization.

So I went back to v5.1.1, and CPU load is like before, nominal until an image change (but have the dup image issue).

Suggestions?

Sorry for the delay getting this to you. Been busy.

The CPU load begins almost immediately after program start-up. From beginning to end the log is only about 6 minutes long.

Another little oddity. When I opened the Settings function, the DisplayFusion.exe CPU usage dropped to zero at the first image change, and DisplayFusionSettings.exe goes from zero to 25 percent. It stays like this for a few moments, then reverts. This cycle repeats at each image change so long as the Settings function is open.

When Settings is not open, CPU usage of DisplayFusion.exe drops to zero just BEFORE the image changes, then goes back up to 25 percent.

I hazard that the program has called a bad process and is stuck in some kind of loop that gets aborted when a timer calls for an image change.

Hope this helps narrow things down.

Here it is again, I hope.

The display change interval is set to 30 seconds on the outbound left and right monitors, and 60 seconds on the center monitor.

I don't have the beta installed anymore, I'm back to v51.1. I previously installed beta6 to create the log you asked for, then immediately uninstalled it. Are the settings from v5.1.1 okay for your needs?

The number of images is about the same as I wrote before: ~2600 for the center monitor, ~14,000 for the left, and ~9500 for the right.
I don't have the 25 percent CPU usage with v5.1.1, nor did I with v6.beta4. I did with v6.beta5 and beta6.

The troubleshooting info is attached.

Haven't we already done this? What's different this time? Are you using entirely different code to manage the screen saver than the wallpaper? Is there a reason the "fix" won't work for both?

Okay. I uninstalled v5.1.1 and installed v6.beta7. With the regular folders (as described previously) CPU usage was actually worse, averaging between 30 percent and 35 percent, although for the few minutes I let it run one or two times CPU usage did drop down to the normal nominal rate for a few seconds.

Next, I created 3 directories and put 5 jpg photos in each, told DF to use those for wallpaper (1 per monitor), and CPU usage stayed nominal, but even with this there was a spike at each image change, up to about 28 percent on average. That's a lot of cycles for a tiny directory listing.

So it would seem that with v6.beta DF has a new problem with wallpaper management sucking up CPU resources.

I'm going back to v5.1.1 till this gets fixed.

Hope this helps.

v6.beta8 is a big improvement on CPU usage! Good job!

I also tried using the screen saver function and it looks like the CPU usage is way down with that too.

Did you change how you enumerate directories?

But I found something else for you to work on next.... Sorry

With the DF screen saver function enabled for the center monitor only (i.e., no screen saver set for the left and right monitors), Preview Mode enabled, Fit Best and Maintain Aspect Ratio, and Span Screen Saver across all monitors enabled, the image strobed/flashed every 1.5 seconds. When I disabled the Span feature, there was no flashing of the image. Image size didn't matter, whether the image was large enough to span across all three monitors, or was small enough to completely fit on the center monitor.

Another little nagging thing I came across this weekend (both v5.1.1 and today with v6.beta8 ), although I think this is a Windows problem. It has to do with cursor focus (something that is frustrating and irritating in Windows already). When I have an application open and I am, in this example, exporting a file, the application opens a save file dialog box, in which I type the new filename. If a wallpaper image change happens while I am typing the new filename, the cursor focus momentarily changes, and when it comes back the partial filename I had been typing is highlighted and then blanked out as I continue typing the remainder of the new filename. Till I figured out what was happening I was getting "confused" as to where the hell my new file was.

I have "focus follows cursor" without AutoRaise, enabled in Windows, a-la X-mouse functionality, but now native in Win7.

This is easy enough to work around now that I know what is happening. (Although if you could fix the Microsoft Windows cursor focus problem that would be great too.

Addendum:

Have another glitch for you to track down: For wallpaper, center monitor changes every 60 sec, left and right monitors every 30 sec. For screen saver, center monitor changes every 30 sec, left and right monitors are blank. When I start the screen saver, left and right monitors blank out and center monitor begins displaying image from its directory, changing every 30 sec (as it is supposed to). After about three cycles (actually, just before the fourth image is about to appear, ~90 sec), the left and right monitors show their desktops (from blank) with the *wallpaper* cycling every 30 sec (but sometimes it doesn't cycle, just showing the last image before the screen saver started), while the center monitor continues showing the *screen saver* cycling every 30 sec. If I move the mouse the desktop reappears on the center monitor with its' wallpaper.

I hope I'm keeping you in good spirits!

Addendum #2:

I think I discovered why the wallpaper cycles sometimes and not others. When I trigger the screen saver manually (e.g., via desktop gadget) the wallpaper on the left and right monitors does cycle. When I let the screen saver start by itself after the timer setting (5 min in my case) then it does *not* cycle.

What I noticed is that when I trigger the screen saver, the wallpaper changes continue to happen even though I can't see them. I know this because when I touch the mouse to stop the screen saver, the wallpaper has changed. But, when I let the screen saver start by itself, the wallpaper changes also stop. And I know this because when I touch the mouse to stop the screen saver, the wallpaper is the same as it was when the screen saver started.

Have fun!

Could you check to see if there has been a regression in the wallpaper selection? While v6.beta8 seems better than v5.1.1, the selection is not "random" or "shuffling" if you prefer.

The "duplicate" image problem seems less (or gone, I'm not sure yet), but there is still a strong bias for "near" versus "far" images. In other words, images that are in the same directory have a much higher probability of being selected next, compared to images in other directories. Same pattern within a directory: If Landscape_1 is selected, then Landscape_2 has a higher probability than Seashore_1.

How are "random" images chosen?

Looks like the CPU usage may not be solved after all. DF v6.beta8 has been running for about 16 hours and I'm seeing DisplayFusion.exe grab 25-27 percent of the CPU for up to a full minute or two at a time before returning to nominal. No pattern that I see so far. Sometimes the nominal usage lasts for a minute or two, other times 15 seconds or so, before returning to ~25 percent CPU. Hmmm.

Downloaded and installed beta9. This one has some problems.

After installing I opened the Desktop Wallpaper configuration via the system tray icon. Clicked OK, the Applying Wallpaper notification box opened, and sat there. After a minute I canceled out of that and just clicked Cancel from the main window. Repeated, same thing. When I tried it 5 minutes later, it worked.

The wallpaper change timing is off. It is supposed to be 60sec (center) or 30sec (left,right). It appears to be varying via some pattern between 15sec and 2min or so. Left and right do change together, but that is about the only consistent thing.

CPU usage is low for now so I'll continue to let it run.

Just FYI, with beta8, when just the screen saver was running, CPU usage remained nominal.

Downloaded beta9_test2, installed. Looking at the Wallpaper configuration worked right off this time. For the few minutes I've been watching it, the image change timing is regular, not like with test1. I do notice that the times are running a little long, instead of 60sec it's about 63-64, similarly a few seconds are added to the 30sec change. Not sure I paid particular attention to this before so don't know if this is "normal" or not.

CPU usage is so far nominal, just a short spike up to ~14-17 percent when there is an image change. I'll let it run for a day or two and if there is a CPU usage problem I'll post a debug log for you.

Promised update: Have had the beta9_test2 build running for several days now and CPU usage has stayed nominal. Both wallpaper and screen saver. Looks like you might have gotten the problem fixed this time (keeping virtual fingers crossed... (Isn't debugging code fun)

The wallpaper selection process seems much better too. I've not noticed any obvious "near" vs "far" filename bias.

There is still the problem with the left and right monitors showing wallpapers when the screen saver is running on the center monitor, but that should be an easy fix.

Looking forward to the next beta!

The two outside monitors have their screen saver set to blank. No; password required is not enabled.

Downloaded the v6.0 final release. Still have the problem with the wallpaper overriding the screen saver. Even when I specify DF as the screen saver for the left and right monitors, after a couple of image changes the wallpaper takes over and replaces the screen saver. (Remember, the screen saver does not blank the left and right monitors when the screen saver is set to Blank.)

As an aside, when the screen saver starts, the center monitor starts immediately. The screen saver on the left or right monitor may start, but are usually blank for a time. And when they do start, they don't necessarily start at the same time.

Also, the wallpaper image selection seems to have regressed. I'll see beach5, beach8, beach3, then sky1. There is no way a random or shuffling selection process would select images like this. Once or twice yes, but not repeatedly. I'm also seeing the same image repeat; not as often as when I started this thread, but repeats nonetheless.

Deleting the history file did help. Been running for a couple of days with no duplicate images showing.

Debugging log is attached. I created two directories with a half-dozen or so files in each, Right-Screensaver and Right-Wallpaper.

Started DF, let the wallpaper cycle once or twice, then started the screen saver. This time all 3 monitors started showing the screen saver images at the same time, usually they don't. After 2 or 3 image changes, the right monitor stopped showing Right-Screensaver images and began showing Right-Wallpaper images. I let this cycle through a few times, then stopped the screen saver and allowed the wallpaper to continue for a couple of change cycles.

Sorry I didn't find an easy bug for you to fix!

Re, "We have it set to expire image history entries that are older than 7 days, but perhaps we need to shorten that up, or make it configurable."

I vote for configurable. I'm guessing you have it set to 7 days to limit the size of the history file. (FYI, when I deleted mine per your suggestion, it was about 4,600,000 bytes in size. As I write this it is up to 3,297,280.) Given the number of images I have, a 7-day expiration will let already-seen-images back into the pool before not-seen ones have been displayed. This might be contributing to why I still think I see duplicate images.

Downloaded and installed v6.01.beta2. Enabled in-memory-collection and changed days-to-expire-image-history from 7 to 30 days. Restarted DF. My first impression is that the image selection seemed to be a bit more "random." I base this in large part on my seeing new images that I haven't seen before. This is of limited reliability though because every time you tweak the algorithm there is a short burst of new images (sort of like getting a new series of random numbers because you're a using a different seed).

Then I noticed some images starting to repeat after an hour or so. And I saw that WallpaperHistoryV4.db hadn't been updated since I restarted DF. I did stop and restart DF, and the file still did not update. After a bit I disabled in-memory-collection, restarted DF, and interestingly, there seemed to be a lot of overlap in the images shown now compared to when I originally enabled in-memory-collection. I did confirm that WallpaperHistoryV4.db was again being updated regularly. (Are you using a different history store for in-memory-collection?)

A day later with days-to-expire-image-history still set to 30 days, image selection is definitely improved. The overwhelming majority of images I'm seeing are "new". FWIW, I opened WallpaperHistoryV4.db with sqlite and there are only about 2800 records in it and covers about a day, according to the timestamps. My image library is 30,000 or so. Is there something non-obvious I am misunderstanding here?

You explained earlier that before every image change DF does a directory enumeration, and in a later post that images can repeat if the current list in DF's memory doesn't have any non-previously-shown images, even though non-previously-shown images still exist in other folders. This means the enumeration is not complete, or there is some pre-selection process (is this the in-memory-collection?). Or something else. Assuming there isn't a bug, the program behavior doesn't seem to match with what I can figure out of the code logic.

As to the wallpaper-screensaver overlap, a new debug log is attached.

Just saw the message that you've posted a beta3.

Here are the results for beta2. I enabled the "Pause wallpaper..." setting and started the screen saver. With no full screen programs running, the behavior was the same as before. When I started a full screen program on the left monitor and then the screen saver, the screen saver image on the left monitor began strobing every couple seconds. After a couple image changes the wallpaper took over aka the previous behavior.

I just looked in the wallpaper history file and it has a bit over 18,000 records in it.

I'll download beta3 and let you know what I find.

And let me say just for the record that it is very unusual for a (software) company to be as responsive to problems as you have been. It's a very pleasant change. Writing code is difficult, more difficult than most people think. And writing good code is harder still, especially with all the permutations you are dealing with. So you have my sympathy and my thanks.

Installed beta3. No change. When I ran a full screen pgm on the left monitor, the image strobed somewhat erratically, with the "Pause wallpaper.." NOT enabled. (See post #36 re strobing with Span mode). Still have the screen saver/wallpaper overlap.

Enabled in-memory-collection, restarted DF. No change. Did confirm that WallpaperHistoryV4.db is updating properly though.

I'll submit log files after the weekend if you want them.

New debug log from beta3 attached.

And I think I found another bug for you.

I grabbed a copy of WallpaperHistoryV4.db this morning and it had 37,369 records in it. I just now created a log file for you, and I grabbed a copy of whv4 to see what the current count was to report to you. It is 2. That is not a typo. Two. Is DF resetting the log file?

Two questions:

1. On the Screen Saver Settings page, of the 3 little monitors at the top, only the center one shows a screen saver image, the left and right monitors have that default image in them. And yes, DF is set to to control all 3 screen savers. In comparison, the Wallpapers Settings page shows wallpaper images on each of the 3 monitors. Is this an oops?

2. In order to minimize the likelihood of showing a previously-used image because DF didn't pre-select enough unused images, should I arrange the images in just a few directories with lot of photos, or many directories with fewer photos? I.e., Few and deep, or many and shallow?

Yes, the right-wallpaper directory has only 5 images in it. I created 2 directories, right-wallpaper and right-screensaver, one has images of animals and the other of landscapes. This makes it easy to tell what is controlling the image being shown on the right monitor, wallpaper or screen saver. The other has 7 images in it.

Another little oddity on the screen saver settings screen. As I said before, the left and right monitor representations on the screen have the default image/symbol shown in them while the center one has a sample image. When I move the cursor over the left or right monitor representations, the cursor disappears. As soon as the cursor passes the image boundary, it reappears.

Info from the troubleshooting tab is attached.

Installed beta4. Still have wallpaper-screensaver problem. With a twist: After the 5min monitor power-off had elapsed, when I moved the mouse to redisplay the screen, the wallpaper changing was frozen. The taskbar icon was nonresponsive so I had to kill displayfusion.exe with task manager. After restarting DF wallpaper changes resumed normally.

Settings file is attached.

That should be fun...

I haven't had DF beta4 freeze again but I am seeing an increase in CPU usage. It's small, but noticeable.

Yes I do. They are set to power off after 10 minutes.

Reminds me of a question I've been meaning to ask. Does the screen saver continue to run after the monitors power off? I don't know if this is a Windows or DF question though.

With all the changes to wallpaper management I decided to delete the history file and start fresh. So I exited DF, deleted WallpaperHistoryV4.db from ...\appdata\roaming\displayfusion\, and restarted DF. But the history file didn't get rebuilt. I did some hunting around and found the new history file in ...\appdata\LOCAL\displayfusion\. A brand new directory.

I decided to make a little lo-res movie to show you what is happening. Pay attention to the right monitor because that is the one I have setup for testing. When it shows landscapes, that is the wallpaper. When it shows animals, that is the screen saver. Also, notice what happens to the desktop when the landscape images return at about 3:13.

I set the screen saver to start after 2 minutes, the overall video is 5 minutes long.

Hope this helps.

Glad the video helped.

On the left monitor there are 9 gadgets.

On the center monitor there are 3 gadgets.

On the right monitor there is 1 gadget.

The screen saver appears to work correctly on the center monitor so I don't think gadgets themselves are the issue.

I've attached 2 photos of the screen saver setting screen. The first one, "a" shows the cursor under the right monitor default image. If I move the cursor up 1 pixel, the cursor disappears.

The second photo, "b" shows what happens when I move the cursor onto the image of the center monitor. The image disappears.

On the wallpaper setting screen, this does not happen. I can move the cursor freely and actual wallpaper images are shown on all 3 monitors.

Sorry for the delay getting back to this (it's a shame how "real" jobs sometimes get in the way

Good call on msconfig. Turns out there is some type of conflict with another program I use called Actual Window Rollup. After a few seconds of inactivity, this program "rolls up" open windows so only the title bar remains. With lots of windows open this helps declutter the screen, and you don't have to constantly drag the cursor down to the task bar to reopen it (for pgms that auto-minimize), just place the cursor in the rolled-up title bar and it "unrolls."

I had v8.1.3 installed. There was an updated v8.1.4 available, but it had only a couple minor changes that didn't relieve the conflict.

This would be a nice feature to add to DisplayFusion. Might be less work than trying to resolve the conflict.

I've only tested the wallpaper/screen saver problem; that's my main concern at the moment. And this was done using the newest DF v6.1.2.

Yes, it does, but it doesn't help. I added every .exe file in the DisplayFusion directory to the exception list. And the interference is only on the left and right monitors, not the center one, so it has something to do with how DF displays screen saver images on those monitors. With wallpaper, DF builds a composite image. How are screen saver images shown?

That did the trick. Thanks!

On the subject of future development and feature requests, the other program I use to manage the UI is WindowFX from Stardock. Quite a few years ago (6? 7?) I asked them if Stardock had a feature to darken inactive windows (a similar effect some web pages use). They said no. Last year when I was hunting around for a program that handled multiple monitor wallpaper, I came across WindowFX.

As you know, when you're working with multiple open windows it is easy to accidentally type something into the wrong one. By darkening the open windows without cursor focus, it is easier to to quickly tell which window you're typing in.

WindowFX does some other things, but all I use it for is to make inactive windows darken and semi transparent. So that would be my feature request.

Grrrrr! I just typed up my reply, clicked Post, and bam! everything disappeared. I usually ctrl-C what I write before I post (not just here, but any forum) to avoid this. But this time I forgot. Grrrrrr!

Yes, I saw the rollup items a few betas back but they require a key sequence to activate. Actual Window Rollup rolls up windows automatically after a user specified time, 30 seconds in my case. While the program works, it also has some problems. First, it doesn't know what to do when the focus-follows-mouse feature (without autoraise) of Windows is enabled. I have this set to a 500 msec delay so windows I am simply moving across don't get focus. This Xmouse-like functionality confuses AWR, especially when the parent window opens a child window or a dialog box. The parent window immediately rolls up when the child gets focus, and if I have to get to another window to look up something, the child immediately rolls up too. And depending on the mouse path I take on the way back to the child, the child can get hidden behind the parent. All the while the windows bounce up and and down like a rubber band completely ignoring the 500 msec or 30 sec delays! And then with programs like Firefox AWR sometimes rolls up to the title bar, other times only to the toolbar. And sometimes a rolled-up window gets stuck and won't unroll, so all I can do is kill the window/program and start it again.

It is very frustrating. To the point that I have most of the programs I use excluded from AWR.

I like the functionality, but not the coding/implementation of AWR.

So here is an "opportunity" for BinaryFortress to show up one of your competitors!

Well, it certainly did roll up everything, including desktop gadgets and wallpaper backgrounds! A couple of desktop pgms I had open unrolled when I highlighted their title bar, others didn't. And none of the gadgets. I didn't know what to highlight/click on for the wallpaper so it just stayed rolled-up.

I eventually had to kill DF to get all the windows/gadgets/wallpapers back.

And yes, I did stop running Actual Window Rollup.

This is on v7.2.0.beta2.

Good first effort though.

Yes I am. And I didn't know it was possible to roll-up wallpapers either!