Open jrkmtf opened 3 years ago
I take it this includes even the example skin I distribute? Strange, I'm running the same Win10 Pro and Rainmeter as you without issue. 1.6.3 didn't change anything beyond fixing some log messages and adding a very simple sanity check to a process step. My first thought might be a different antivirus causing issues with Chameleon? I'm using Defender.
Yep, even with the example skins. I just updated everything on another machine running Windows 10 1909 - same version of Rainmeter and Chameleon - no issue.
I'm using Defender on one PC (21H1) and Sophos on the other (20H2 - this is a work machine so I can't turn AV off). I tried watching the Rainmeter log while loading a skin and did not see any error messages. Could it have anything to do with hardware acceleration?
EDIT: I'm using hardware acceleration on one machine (21H1) but not the other (20H2) so I'm thinking it's unrelated.
Another edit: I don't know that the behavior began after updating to 1.6.3 - could have started before. It's most definitely an issue on my side, and not with the plugin - I just have no logs or errors to help me troubleshoot the issue.
I can't imagine it, since Chameleon doesn't actually do anything that touches HW acceleration. I doubt it's an issue with trying to access the image to sample, but it's a possibility?
Hmm, that's a good thought. My wallpapers are saved on OneDrive, though always synced to local storage so there shouldn't be any "cloud" issues. I'll try moving an image off of OneDrive and see if anything changes.
UPDATE: Changed to an image file on my desktop - no change. My old wallpaper was quite large, 6400x4000, so I tested with a 1920x1080 image and also no change.
Yeah, Chameleon resizes the image to 256x256 before sampling to avoid the whole "huge image" thing (I have a few high res desktops myself). I was thinking the OneDrive thing could have been a good lead but apparently not.
What happens if you edit the skins to have a very low refresh rate (like 1000ms or something)?
Well...now we're getting somewhere. Changing the sample skin to Update=1000 for the Socks suite seems to have vastly improved performance. Checking the rest of my skins, a few of them (one of them a visualizer) had an update of 16.
The Rainmeter GUI is still laggy and seems to get worse as I load more skins that use Chameleon. Is there a way to optimize the use of Chameleon with a single skin so as to prevent multiple skins from each individually calling the plugin?
I don't believe there's a way to do anything like that, and it would still just be a bandaid on the actual issue. Even the reduced update rate is not an ideal solution. One of my plans was to eventually make it so that Chameleon stores the color data plugin-wide instead of per skin though. That'll probably be in the 1.7 release once I've wrapped up some other projects.
This does tell me that it's probably something Chameleon is interacting with, and I'm betting it's either Chameleon trying to figure out what the wallpaper file is, or it trying to actually read the file. Have you tried using a fixed reference to the wallpaper file using the File
type with the path to the wallpaper instead of the Desktop
type?
I'm not sure what changed on my system, but any time I load a skin which uses the Chameleon plugin it causes Rainmeter to freeze and the rest of Windows becomes incredibly slow. I can't interact with the Rainmeter GUI and have to force close the process and manually edit Rainmeter.ini to unload these skins. I experience this behavior on two different systems: Windows 10 Enterprise (20H2, 19042.1165) and Windows 10 Pro (21H1, 19043.1165). Both are running Rainmeter 4.5.0.3518 (64-bit) and using Chameleon 1.6.3.