https://www.displayfusion.com/Discussions/RSS/?TopicID=637a71a6-17ae-441d-8cce-c28ff7f4ce36 DisplayFusion RSS: DisplayFusionCommand slow to respond Sat, 20 Jun 2026 00:34:53 GMT en hourly 1 https://www.displayfusion.com/Discussions/RSS/?TopicID=637a71a6-17ae-441d-8cce-c28ff7f4ce36 https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36#3 Thu, 16 Dec 2021 17:05:48 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36#3 DisplayFusion Testing WallpaperUseInternalProcessing=1 is no faster when initiating wallpaper changes as a keyboard shortcut, sadly.

Setting WallpaperUseInternalProcessing also seems to omit the wallpaper change animation; not sure whether that's intended. ]]> https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36#2 Thu, 16 Dec 2021 16:36:01 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36#2 DisplayFusion We took a look into this, but unfortunately there isn't a way to have it sitting in memory waiting.

This advanced setting might help you out, by avoiding the DisplayFusionCommand entirely: https://www.displayfusion.com/AdvancedSettings/#wallpaper_useinternalwallpaperprocessing

Hope that helps! ]]> https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36 Tue, 16 Nov 2021 13:07:02 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/displayfusioncommand-slow-to-respond/?ID=637a71a6-17ae-441d-8cce-c28ff7f4ce36 DisplayFusion Hi,

Been a user since 2011. Great software. No longer use the multimonitor taskbar since Windows 10 but I still use the wallpaper changer.

Question: on my system, DisplayFusionCommand takes ~3-6s to respond (on e.g. -wallpapertoggle reverting all wallpapers to black). A look at ProcMon shows this:

Much of the registry reads are on HKLM\System and the subsequent I/O read is loading .NET4 assemblies it seems

Is this performance normal? Is there a way to preload DisplayFusionCommand to be passively listening? ]]>