[BUG?] Selecting a gif wallpaper on the wallpaper selector using swww eats up ALL the RAM in the system.

[Yhuot]

Describe the bug

Alright, i just installed ML4W, looks amazing, and one of my favorite features is the one that changes the colors on everything based on your wallpaper, ISSUE BEING, when i select a gif in the wallpaper selector to be put on swww, the computer starts lagging like hell and all my 16Gb of RAM and 10Gb of Swap are consumed by both the display process (don't ask me, the process is called display) and the magick process, i'm not sure why this happens, memory leak? dunno, HOWEVER, when i do it via command "swww img ./nice-wallpaper-gif" it works no issue, the wallpaper is loaded and my RAM doesn't become toast, but the colors changing feature is gone too, like, is this intended? can i do anything to fix it?

Steps to reproduce

1. install swww
2. open wallpaper app
3. switch to swww and select a gif
4. watch your RAM be drained

Expected behavior

Well, the expected is selecting the wallpaper, the wallpaper changing and the colors being changed too, without my compuner using all the RAM+SWAP to do this.

Screenshots

No response

Distribution

Arch Linux

If Other, specify

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[mylinuxforwork]

@Yhuot Thanks for testing and your feedback. Your finding is not a dotfiles issue. Can you open an issue on waypaper GitHub?

[Yhuot]

Understood

[anufrievroman]

Hi, waypaper dev here. It is the issue with the dot files, actually. It is caused by the wallpaper.sh that does all these processes (magik etc), I think. By itself, waypaper doesn't launch anything like that. Here is more information.

[mylinuxforwork]

Hi, waypaper dev here. It is the issue with the dot files, actually. It is caused by the wallpaper.sh that does all these processes (magik etc), I think. By itself, waypaper doesn't launch anything like that. Here is more information.

Hi. Thanks for your feedback. It really could be that the imagemagick procedures don’t work with Gifs.

[anufrievroman]

If it helps, this issue is also seems to have the same problem

[ENERGIUM]

Hello, I fall if I can publish here, but I think that excessive consumption of memory is due to the generation of the blurred image and the square image for miniatures.
I solve this by modifying the script wallpaper.sh adding conditions and extracting the first image of the Gif to work with Imagemagick.
I can include the code if they need it.
I am in version 2.9.7.2
Excuse me if this message is not understood much since I am using a translator.

[mylinuxforwork]

Hello, I fall if I can publish here, but I think that excessive consumption of memory is due to the generation of the blurred image and the square image for miniatures. I solve this by modifying the script wallpaper.sh adding conditions and extracting the first image of the Gif to work with Imagemagick. I can include the code if they need it. I am in version 2.9.7.2 Excuse me if this message is not understood much since I am using a translator.

Yes. This can be the reason.

[Yhuot]

Hello, I fall if I can publish here, but I think that excessive consumption of memory is due to the generation of the blurred image and the square image for miniatures. I solve this by modifying the script wallpaper.sh adding conditions and extracting the first image of the Gif to work with Imagemagick. I can include the code if they need it. I am in version 2.9.7.2 Excuse me if this message is not understood much since I am using a translator.

Half of it is, after i disabled it, it went from magick and display taking 7.2 Gb RAM each, to only display taking 14.4 Gb of it

[Yhuot]

mayhaps i forgot to mention that info lol, mb, also, the display process RAM "leak" is started by the pywal part of wallpaper.sh, which i have given up on (solving) (removing) because i like the auto color scheming, but yeah, there's that happening.