Wallpaper not changing too slow when the overlay is used

[NyaMisty]

When I used the desktop overlay together with the wallpaper functionality, I quickly switched the desktop twice by using the 4-finger gesture. I'm expecting the wallpaper changing very fast, as the wallpaper on the first desktop did changed quickly, but I noticed the second desktop's wallpaper are not changed until the first overlay disappeared. Change the overlay duration and you can see it more clearly. After disabling the desktop overlay, the problem gets solved, but I really want to use them together. Maybe a bug?

[NyaMisty]

Also when switching quickly I want the wallpaper change directly instead of changing to picA then changed to the target picB.

[mzomparelli]

Thanks for the feedback. I will look into this tonight.

[NyaMisty]

OK, Thanks~

[mzomparelli]

I published an update (1.0.88.6) that should reduce the time to change desktop background in your situation. It's not an update that will prompt you so you have to press the "Force Update" button in the lower left of the settings window. Let me know if this helps.

[NyaMisty]

Still not help much :( It seems that the overlays are working in a synchronous way, which is causing the whole program freezing while the overlay is displaying. I doubt it has something to do with your way to create the overlay window.

[NyaMisty]

Maybe we shouldn't sleep on the UI thread? Though creating a new thread, it seems that all messages are all on the same queue, but according to MSDN every thread should have its own message queue, which is quite strange.

[NyaMisty]

I've got what's happening. During the overlay's load, the HideDesktopView is invoked, which is dispatched to the main thread immediately. But then the second overlay is loaded, and the HideDesktopView is invoked once again, but the invocation is synchronous, causing the main thread locked, which finally caused the VirtualDesktop message failed to dispatch. :( That's the cause of the situation described above. Another cause of wallpaper changed slowly is because SetWallpaper and StopSlideShow executes very slow, and both CurrentChanged and CurrentChanged2 are executed on the same thread sequentially, so the wallpaper can only change in a one-by-one manner. I did see you created two threads for each of them, but in fact these messages are dispatched in other threads, and calling them in those two threads has no effect at all :(

So I strongly advice that you make the CurrentChanged and CurrentChanged2 or even Wallpaper.Set work asynchronously. PS: C# itself has advanced but quite easy-to-use async keyword, why not give it a try ;)

[mzomparelli]

Wow! You dived right into it.

CurrentChanged and CurrentChanged2 should be executing on their own thread and both are separate from the UI thread. It's not as easy to see this without the use of async keyword.

I think I might actually remove the slideshow. I personally don't like the way that is implemented and doing it caused me to make changes to SetWallpaper. Let me look into that.

The implementation of the overlay isn't good so I'm going to start there and see what I can do.

[NyaMisty]

Yeah but it seems that it's executed by another worker thread and neither of the thread wake up to process the message, I doubt that the it's a global object which will only dispatch notification on its own worker :(

[NyaMisty]

As for the slideshow, I wonder why we don't use the original one from explorer, which also have a good animation.

[NyaMisty]

Well after some search it seems that the slideshow.ini which encodes the slideshow parameters is not public struct. Maybe I can reverse engineering it. I'll have a try tomorrow.

[mzomparelli]

I really appreciate your input. You sound very skilled in programming. As you can tell from my code I'm not the best. What I have is good ideas and enough programming knowledge to make it work. As I was adding new functionality I didn't go back and change the structure of the code. Instead, I tweaked areas to make it work. I don't think what I've done is too bad and it certainly works for the most part :)

As I dig into this more I can see how badly the overlay is implemented. There must be a better way to show a screen overlay without using a form. I'm thinking I need to draw directly to the screen instead. What do you think about that and do you have any suggestions?

I changed the thread sleep in overlay to a stop watch. This appears to correct some of the bad behavior, but work is still needed to the overlay implementation. Force an update and let me know what you think about using a stop watch in place of the thread sleep.

[mzomparelli]

In my testing, the stop watch seems to be pretty good in place of the thread sleep. I'm looking forward to your feedback on the update.

[NyaMisty]

In fact I'm a reverse engineer, with a little debugging skill, and my main language is C and C++. Actually for programmer, many problem aren't that clear, but if you think reversely in another way, then things will get simple and straightforward. When I looked into your wonderful tool, I feel that most your code is pretty good, tidy, with no garbage, so please don't worry. And in fact what most programmers doing is tweaking somewhere everyday.(Haha As for the overlay, you do have a good instinct ;). Usually overlay are implement using GDI+, directly drawing on the screen DC.

[NyaMisty]

Maybe I should also open another issue for the slideshow?

[mzomparelli]

Yes please, slideshow in another issue so that the discussion doesn't get too difficult to follow.

[NyaMisty]

I tested it and it wallpaper changed very smoothly, I'll close this issue 👍

[mzomparelli]

ok, thanks for the info. I will continue to tweak it to make it better.