Code Monkey home page Code Monkey logo

swww's Introduction

A Solution to your Wayland Wallpaper Woes

Efficient animated wallpaper daemon for wayland, controlled at runtime

animated gif demonstration image transition demonstration

Dependencies

  • a compositor that implements:
    • wlr-layer-shell (typically wlroots based compositors)
    • xdg-output
  • lz4 (for compressing frames when animating)

Note that this means swww will not run on Gnome, because it does not implement the wlr-layer-shell protocol.

Build

Packaging status

Dependencies:

  • Up to date stable rustc compiler and cargo (specifically, MSRV is 1.74.0)

To build, clone this repository and run:

cargo build --release

Then, put both binaries target/release/swww and target/release/swww-daemon in your path. Optionally, autocompletion scripts for bash, zsh, fish and elvish are offered in the completions directory.

Man pages:

In order to generate the man pages, you must have scdoc installed. Run

./doc/gen.sh

The man pages will be in doc/generated. To install them, you must move them to to the appropriate location in your system. You should be able to figure out where that is by running manpath.

Features

  • Display animated gifs on your desktop
  • Display any image in the formats:
    • jpeg
    • png
    • gif
    • pnm
    • tga
    • tiff
    • webp
    • bmp
    • farbfeld
  • Clear the screen with an arbitrary rrggbb color
  • Smooth transition effect when you switch images
  • Do all of that without having to shutdown and reinitialize the daemon

Why

There are two main reasons that compelled me to make this: the first is that oguri is unmaintained and archived, despite there being serious problems with excess of memory use while displaying certain gifs (see this, for example). The best alternative I've found for oguri was mpvpaper, but if felt overkill for my purposes.

Comparing to oguri, swww uses less cpu power to animate once it has cached all the frames in the animation. It should also be significantly more memory efficient.

The second is that, to my knowledge, there is no wallpaper daemon for wayland that allows you to change the wallpaper at runtime. That is, in order to, for example, cycle through the images of a directory, you'd have to kill the daemon and restart it. Not only does it make simple shell scripts a pain to write, it makes switching from one image to the next to happen very abruptly.

Usage

Start by initializing the daemon:

swww-daemon

Then, in a different terminal, simply pass the image you want to display:

swww img <path/to/img>

# You can also specify outputs:
swww img -o <outputs> <path/to/img>

# Control how smoothly the transition will happen and/or it's frame rate
# For the step, smaller values = more smooth. Default = 20
# For the frame rate, default is 30.
swww img <path/to/img> --transition-step <1 to 255> --transition-fps <1 to 255>

# There are also many different transition effects:
swww img <path/to/img> --transition-type center

# Note you may also control the above by setting up the SWWW_TRANSITION_FPS,
# SWWW_TRANSITION_STEP, and SWWW_TRANSITION environment variables.

# To see all options, run
swww img --help

If you would like to know the valid values for <outputs>, you can query the daemon. This will also tell you what the current image being displayed is, as well as the dimensions detected for the outputs. If you need more detailed information, I would recommend using wlr-randr.

swww query

Finally, to stop the daemon, kill it:

swww kill

For a more complete description, run swww --help or swww <subcommand> --help.

Finally, to get a feel for what you can do with some shell scripting, check out the example_scripts folder. It can help you get started.

Transitions

Example wipe transition:

wipe transition with angle set to 30 deg

top transition demonstration

The left, right, top and bottom transitions all work similarly.

Example outer transition

outer transition demonstration

The center transition is the opposite: it starts from the center and goes towards the edges.

There is also simple, which simply fades into the new image, any, which starts at a random point with either center of outer transitions, and random, which selects a transition effect at random.

Troubleshooting

The image looks tilted and in grayscale on my laptop

See #233. Current workaround is to use swww-daemon --format xrgb when starting the daemon.

High cpu usage during caching of a gif's frames

swww will use a non-insignificant amount of cpu power while caching the images. This will be specially noticeable if the images need to be resized before being displayed. So, if you have a very large gif, I would recommend resizing it before sending it to swww. That would make the caching phase much faster, and thus ultimately reduce power consumption. I can personally recommend gifsicle for this purpose.

Wallpaper disappears when reconnecting monitor

swww used to cache its images so that it could reload the current the last displayed image automatically. This lead to many problems and also proved to be very annoying to keep working with when we updated to sctk 0.17. So I decided to nuke it.

If you want a wallpaper to be set automatically when you reconnect to a monitor, you should use a combination of scripts and a program that lets you run commands when a new output is connected, like kanshi.

About new features

Broadly speaking, NEW FEATURES WILL NOT BE ADDED, UNLESS THEY ARE EGREGIOUSLY SIMPLE. I made swww with the specific usecase of making shell scripts in mind. So, for example, stuff like timed wallpapers, or a setup that loads a different image at different times of the day, and so on, should all be done by combining swww with other programs (see the example_scripts for some examples).

If you really want some new feature within swww itself, I would recommend forking the repository.

Alternatives

swww isn't really the simplest, mostest minimalest software you could find for managing wallpapers. If you are looking for something simpler, have a look at the awesome-wayland repository list of wallpaper programs . I can personally recommend:

  • wbg - probably the simplest of them all. Strongly recommend if you just care about setting a single png as your permanent wallpaper on something like a laptop.
  • swaybg - made by the wlroots gods themselves.
  • mpvpaper - if you want to display videos as your wallpapers. This is also what I used for gifs before making swww.

Acknowledgments

A huge thanks to everyone involved in the smithay project. Making this program would not have been possible without it. In fact, the first versions of swww were quite literally copy pasted from the layer shell example in the client-toolkit .

A big thank-you also to HakierGrzonzo, for setting up the AUR package.

Wallpapers used in this README

Pixel Art, by Waneella - https://www.patreon.com/waneella

Gradient - https://www.behance.net/gallery/86128681/Free-Unicorn-Vector-Gradients

Silhouette of Skyway - https://unsplash.com/photos/silhouette-of-skyway-UUJzCuHUfYI

swww's People

Contributors

ahji26 avatar akida31 avatar aouerf avatar b3nj5m1n avatar beanigen avatar diaoul avatar doannc2212 avatar flick0 avatar fuyukai avatar hkupty avatar hsnovel avatar iynaix avatar lgfae avatar lucasreis1 avatar m4rch3n1ng avatar mausworks avatar max-ishere avatar michaeloultram avatar micielski avatar musjj avatar potatoattack avatar riedlerod avatar signalwalker avatar thebenperson avatar thedmm avatar whynothugo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

swww's Issues

WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited

I use wayland/wayfire on Arch , it was working fine with swww-git version , previously using swww from aur was throwing error like cache path not found but after using swww-git version it resolved , it was working fine but when i logout from my Wms using loginctl and logged back it did not start ,
i tried ,
swww init
but not starting daemon :
WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited
Error: "Failed to receive answer: io error: Connection reset by peer (os error 104)"

throwing this error
i tried removing swww.socket but not worked .

Repeated transition

I use swww with the following script:

#!/usr/bin/env sh

swww init

while true;
do
  echo "Changing image"
  swww img $(~/.config/sway/scripts/wallpaper.sh) --transition-step 3
  sleep 55
done

where wallpaper.sh returns the path of a random wallpaper.

Occasionally, I observe the following bug:

  • At first, swww works normally.
  • A transition happens, triggered by the script swww img command.
  • A few seconds later, the wallpaper abruptly (with no transition) reverts to the previous image (the beginning of the transition), and the transition repeats. This happens over and over until the next swww img command gets issued.
  • swww again works normally (until the bug appears again after some later img command).

Smaller sized GIFs don't load on startup, but larger ones do

Hello! I am grateful for this amazing program and love everything about it

I have a small library of GIFs that I use to switch wallpapers from time to time to keep things fresh.

However, I have noticed a peculiar issue where GIFs with smaller sizes (<1MB) sometimes, or don't load at all at startup. However, GIFs with relatively larger sizes (say 2MB and greater) have no issues whatsoever loading in on startup.

These 2 GIFs are of different resolutions.

Do note, that once I manually execute swww img /PATH/TO/GIF, the wallpaper sets itself, regardless of the resolution

I only use a single monitor(1600x900), with my laptop monitor being disabled by the WM itself.

I am using hyprland WM with the following lines in my config file which correspond to my wallpaper set up

exec-once = swww init
exec-once = swww img /PATH/TO/GIF

In both the cases, I have confirmed that swww init was running. I am also going to attach the GIFs in question that I have used to test my theory

This GIF doesn't work
This GIF works

I am not sure if I can provide any log files, as afaik, swww doesn't provide any logging options

cannot build

hi there :) thanks for your work.

I am trying to build. new with rust, so forgive me if this is a simple issue.


jaymedavis@jayme-port-fedora swww]$ cargo build --release
   Compiling smithay-client-toolkit v0.16.0
   Compiling swww v0.7.2 (/home/jaymedavis/Source/swww)
   Compiling keyframe v1.1.1
   Compiling image v0.24.5
   Compiling fast_image_resize v2.5.0
warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
error: failed to run custom build command for `smithay-client-toolkit v0.16.0`

Caused by:
  process didn't exit successfully: `/home/jaymedavis/Source/swww/target/release/build/smithay-client-toolkit-fccdcef68e554481/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=XKBCOMMON_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=XKBCOMMON_STATIC
  cargo:rerun-if-env-changed=XKBCOMMON_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"xkbcommon\"` did not exit successfully: exit status: 1\nerror: could not find system library 'xkbcommon' required by the 'smithay-client-toolkit' crate\n\n--- stderr\nPackage xkbcommon was not found in the pkg-config search path.\nPerhaps you should add the directory containing `xkbcommon.pc'\nto the PKG_CONFIG_PATH environment variable\nPackage 'xkbcommon', required by 'virtual:world', not found\n"', /home/jaymedavis/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.16.0/build.rs:5:49
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

libxkbcommon is installed. just pulled source and ran cargo build --release. what am I missing?

cheers

Wallpaper set to lower than native res on HiDPI

Hi, I've installed swww out of curiosity, and everything has been okay except the title of this issue.

I have noticed how wallpapers get set to a 1280x720 resolution (as reported by swww query)¹, even though my native res is 2560x1440 and so is the wallpaper's.
They look pixelated, same way that xwayland programs look due to scaling issues between sway trying to go for e.g 150% but x11 staying at 100%, giving it the same pixelated effect.

Examples

image
image

Additional context

I've compiled this program using Nix and made a derivation for it, including a module and systemd service here (line 394).
The systemd services successfully start, wallpaper gets set, so the binary works as well. If I set any random image as a wallpaper using e.g swww img random.png, it gets the same issue.

¹ swww query returns eDP-1 = 1280x720, currently displaying: image: "bg3.png"

System info

Distro: NixOS (22.11.20220824.b784c5a)
WM: Sway
Device: ThinkPad T480
Display: QHD (2560x1440)
swww -V: swww 0.4.2

Performance issues with bezier in 0.6.0

@flick0 since you are the main contributor here
I think nothing illustrates this better than a video. The options used here are:
--transition-step 1 --transition-type any --transition-duration 5 --transition-fps 255 --transition-bezier=0.85,0,0.15,1

0.6.0_v2.webm

Even using "no beziers" it is still pretty slow.(--transition-bezier=0,0,1,1)

no_bezier.webm

I know that bezier is a bit performance heavy, but compared to the last release(0.5.0), it's noticeably faster than both of the above
Options used here are: --transition-speed 20 --transition-type any --transition-fps 255

0.5.0.webm

[Feature request] Allow scalling without filtering (for pixel art)

Hello!

When using animated gif pixel art it would be nice to be able to keep the crispy square pixels even if the original art has a very small resolution compared to the display resolution.

Currently I'm doing the conversion with gifscicle but it creates huge gifs which can take up to 10 seconds to be loaded by swww.

When I load the original gif it is loaded almost instantly but clearly has some filtering making the pixels look fuzzy/blurry.

Thanks for such a great application!

cargo build --release >> FAILED

Here is the error

warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
warning: ran fix_zsh_completion.sh script.
   Compiling swww v0.6.0 (/home/luxluth/Softwares/swww)
   Compiling swww-daemon v0.1.0 (/home/luxluth/Softwares/swww/daemon)
/home/luxluth/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-d0d50995ab5830a5.so(+0x30e3f33)[0x7f2282ee3f33]
/usr/lib/libc.so.6(+0x38a00)[0x7f227fc51a00]
[0x7f2266bf9b8f]
error: could not compile `swww-daemon`

Caused by:
  process didn't exit successfully: `rustc --crate-name swww_daemon --edition=2021 daemon/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=3391a53e699c0a8e -C extra-filename=-3391a53e699c0a8e --out-dir /home/luxluth/Softwares/swww/target/release/deps -C linker=clang -C strip=symbols -L dependency=/home/luxluth/Softwares/swww/target/release/deps --extern keyframe=/home/luxluth/Softwares/swww/target/release/deps/libkeyframe-ce70edb7e446baea.rlib --extern log=/home/luxluth/Softwares/swww/target/release/deps/liblog-786fbf621861e7e9.rlib --extern simplelog=/home/luxluth/Softwares/swww/target/release/deps/libsimplelog-10ce44a333451d4c.rlib --extern smithay_client_toolkit=/home/luxluth/Softwares/swww/target/release/deps/libsmithay_client_toolkit-9720adc25f2b5202.rlib --extern utils=/home/luxluth/Softwares/swww/target/release/deps/libutils-f8f874f9639a6a2d.rlib -C link-arg=-fuse-ld=mold -L native=/usr/lib -L native=/home/luxluth/Softwares/swww/target/release/build/lzzzz-0d4c38b91445ca09/out` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
/home/luxluth/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-d0d50995ab5830a5.so(+0x30e3f33)[0x7f2be3ee3f33]
/usr/lib/libc.so.6(+0x38a00)[0x7f2be0acba00]
[0x7f2bc3bf9d8f]
The following warnings were emitted during compilation:

warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
warning: ran fix_zsh_completion.sh script.

error: could not compile `swww`

Caused by:
  process didn't exit successfully: `rustc --crate-name swww --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=35a396be4b4feabe -C extra-filename=-35a396be4b4feabe --out-dir /home/luxluth/Softwares/swww/target/release/deps -C linker=clang -C strip=symbols -L dependency=/home/luxluth/Softwares/swww/target/release/deps --extern clap=/home/luxluth/Softwares/swww/target/release/deps/libclap-5143ad88642ef8ce.rlib --extern fast_image_resize=/home/luxluth/Softwares/swww/target/release/deps/libfast_image_resize-2c348cceaaaff75e.rlib --extern image=/home/luxluth/Softwares/swww/target/release/deps/libimage-95628370f2e2e1ad.rlib --extern rand=/home/luxluth/Softwares/swww/target/release/deps/librand-3c00f24cb7f97880.rlib --extern utils=/home/luxluth/Softwares/swww/target/release/deps/libutils-f8f874f9639a6a2d.rlib -C link-arg=-fuse-ld=mold -L native=/home/luxluth/Softwares/swww/target/release/build/lzzzz-0d4c38b91445ca09/out` (signal: 11, SIGSEGV: invalid memory reference)

cargo build works fine

Failed to receive answer: io error: Resource temporarily unavailable (os error 11) when plugging or unplugging display

I'm running swww version 0.4.3 on Arch, using Sway as the compositor.
Running sway init and then setting an image as the background works, when using my laptop display alone, or using my laptop's display plus an external display that is plugged in.

However, when the swww daemon is running and I plug / unplug the display, the daemon gets into a state where it can not be communicated with.

Setting the background with:
swww img --transition-speed=1 --transition-step=1 ~/Pictures/my_wallpaper.png
results in:
Failed to receive answer: io error: Resource temporarily unavailable (os error 11)

Running swww kill results in the same error.

I can only get it running again by killing the process, and removing the socket manually.

Crashes with FFMPEG gifs

Hey, I recently decided to make my own wallpaper gif with ffmpeg, but whenever I run swww init and swww img path/to/the/gif it displays the first frame with the fading in animation and drops to default Sway background (I use Sway).

The gif.

I used this command to get the gif (However, I used other commands to get the input.gif):

ffmpeg -i input.gif -filter_complex "fps=30,scale=1920:1080,split[a][b]; [a]palettegen=stats_mode=full [palette]; [b][palette]paletteuse=dither=sierra2_4a" output.gif
$ swww --version
swww 0.6.0

How to make UHD image fit to screen

I have some larger U/HD images that exceed the screen real estate when using this tool.

What commands are available to make it only fit to screen (usually called stretch or fit)

FR: Supply a cache file instead of GIF?

I have a nice animation on boot that transitions to a static image. In #93 I have figured out that you can

swww img i.gif
swww kill
swww init

and the loading time in init is basically 0. So is there a reason we cant have a command that makes the daemon perform those really fast steps that happen in init, but for loading the GIF while it is already running?

Span image over all monitors.

Would it be possible to allow an image to be spanned over multiple monitors?
I could try to implement this myself. I would just need a hint, where in the code the image is drawn on a specific output.
I gues I would just need to split the image data into n chunks and then send them to the appropriate outputs.

daemon unsets on screen shutdown

I'm Not sure if it's intended behavior, so i'll refrain from assigning a label.

Upon physically powering off a screen, swww doesn't kill the daemon but unsets itself. On screen powerup i need to manually use the swww img command to set the image again.

Is it possible to store the loaded image and when swww detects a screen powering on (and thus swww query returns the screen data) to autoload what was previously on that screen?

query returns wrong info

swww reports wrong dimensions:

> swww query
DP-2 = 4586x1920, currently displaying: color: 000

Sway reports the correct sizes:

> swaymsg -t get_outputs
Output DP-2 'Ancor Communications Inc ROG PG348Q #ASMuhJCcVsHd' (focused)
  Current mode: 3440x1440 @ 59.973 Hz
  Position: 0,0
  Scale factor: 1.500000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 2 2:二
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    3440x1440 @ 59.973 Hz
    3440x1440 @ 49.987 Hz
    1024x768 @ 60.004 Hz
    800x600 @ 60.317 Hz
    640x480 @ 60.000 Hz
    640x480 @ 59.940 Hz

Output eDP-1 'Sharp Corporation 0x148B Unknown' (inactive)
  Available modes:
    3840x2160 @ 59.997 Hz

Add helpful error message when trying to use swww without daemon running

When running a command without first initializing the daemon you get this error message.
Error: "Failed to connect to socket: No such file or directory (os error 2)"
It's not immediately obvious what the problem is.

I think it would be helpful if a suggestion to check if the daemon is running was added (as a second line maybe?).
Something like this could work.
Is the swww daemon running?

how to compile this app?

Hi, noob question here... never compiled with cargo.
I get this: is listed in workspace’s default-members but is not a member.

Version 0.4.0 streches the wallpaper

Hi! Thanks for working on this fun little program!

I have found a bug/regression between versions 0.3.0 and 0.4.0.

Issue

There is an undocumented change when scaling the wallpaper image. In 0.3.0 swww used to fill the wallpaper, now it streches the image.

On version 0.4.0 and master

When The requested wallpaper image has a different aspect ratio then the target output.
Then The displayed image is stretched.

On version 0.3.0

When The requested wallpaper image has a different aspect ratio then the target output.
Then The displayed image is zoomed in.

Can we return the old behavior or turn it into an option?

Environment:

$ swww query
DP-2 = 2560x1440, currently displaying: image: "wallpaper.bmp"
HDMI-A-1 = 2560x1080, currently displaying: image: "wallpaper.bmp"
  • Window manager - sway
  • DP-2 is a 16:9 4k screen with 1.5 scaling, HDMI-A-1 is a 21:9 ultrawide.
  • wallapaper.bmp is a 1080p 16:9 image.

`--transition-duration` to control transition duration

Description

Currently the speed of the transition must be configured via --transition-step and --transition-speed. Tweaking these values require some pretty delicate understanding of the how transitions are implemented, keeping in mind screen resolution, and possibly some basic math.

I believe the current approach is designed this way since it directly exposes the internals of the transitions implementations.

Possible improvement

I'd like to propose merging these into a --transition-duration flag, which merely takes an integer with the transition duration in milliseconds. This is something a lot "friendlier" and handles just one value that's very simple to understand.

The correct values for transition-speed and transition-step can be calculated based on --transition-duration and --transition-fps.

Saner default for `transition-step` with `simple` transition

When did the issue start?

Since updating to the latest version, a week or two ago. I don't know for sure what the old version i was using was.

What is the issue?

The fade-in animation swww used to have when setting new wallpapers stopped working all of a sudden, so i had to change my configs to use other animations, which seem to work normally.
When using the command manually, i noticed it gave me an error: failed to get cache path: failed to create cache_path: No such file or directory (os error 2).

What did i do to try and fix the issue?

Looked up the man pages and saw it would look for cache files in $XDG_CACHE_HOME/swww or $HOME/.cache/swww. ~/.cache/swww seemed to not exist so i made a new folder with the same name: nothing changed.
I didn't have XDG_CACHE_HOME set, so i used XDG_CACHE_HOME=~/.cache/ swww img <PATH> to fix the issue, which worked in the sense that it stopped giving me the warning about the cache path, but still couldn't get the fade-in animation working.

System information

  • CPU: AMD Ryzen 5 4600G with Radeon Graphics (12) @ 3.7GHz
  • GPU: AMD ATI 30:00.0 Renoir
  • swww: swww 0.7.2
  • Rust: rustup 1.25.2-1, rustc 1.67.0
  • Distro: Arch Linux, 6.1.11-zen
  • WM: Hyprland 0.21.0beta-2

BUG: Unknown cause, GIF dont play, but hang on one frame and clear cycles through frames and doesnt clear

First mention: #93 (comment)
#93

Steps to reproduce

  1. <In the process of figuring out step 1>, see Potential causes.
  2. Call swww img any_gif_doesnt_matter.gif

Actual behavior

GIF may play for less than a second and then stops.
Calling swww clear only "unpauses" the GIF for a short instant.

How to fix

Restart the daemon with swww kill ; swww init

Potential causes

Calling swww img many times concurrently? It is hard to figure out as of now.

Priority

Since the exact causes are unknown and the issue does not happen often I consider the priority to be low. This may only affect users that run swww on gifs very frequently (e.g. to chain gifs or because 2 swww scripts are running at the same time).

Support for "cleaning" the images from ram

Currently(at least from what I've observed), swww will put every image you load into ram, which is not great since I change my wallpapers quite commonly
I hope that there could be a subcommand that will "clean" everything except the currently loaded wallpaper
Maybe sth like cleancache

swww crashes with '[SCTK] A missing global was required: zwlr_layer_shell_v1'

built the program with cargo build --release

Trying to run the daemon:

> ./swww init --no-daemon
WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited
thread 'main' panicked at '[SCTK] A missing global was required: zwlr_layer_shell_v1', /home/luis/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.16.0/src/environment.rs:193:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[1]    149731 IOT instruction (core dumped)  ./swww init --no-daemon

env:
cargo 1.65.0
rustc 1.65.0 (Arch Linux rust 1:1.65.0-1)

Let me know if you need more information.

`failed to get cache path`

I believe the error:

$ swww img example.gif
failed to get cache path: failed to create cache_path: No such file or directory (os error 2)

is caused by utils/communication.rs:324.

I tried to create .cache/swww but it still gives me this error.

$ stat $HOME/.cache/swww
  File: /home/max_ishere/.cache/swww
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 254,2	Inode: 395962      Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/max_ishere)   Gid: ( 1000/max_ishere)
Access: 2023-02-19 17:20:30.772317103 +0200
Modify: 2023-02-19 17:20:30.772317103 +0200
Change: 2023-02-19 17:20:30.772317103 +0200
 Birth: 2023-02-19 17:20:30.772317103 +0200

I dont know if this is related but after calling swww clear and then displaying a gif (swww img example.gif) is hangs on the first frame for quite some time. Would be nice if the first frame would only appear after swww is ready to play the entire gif.

Plans for the Future

I decided to write this in order to clarify some things I wrote in the README.

First of all, I already changed the code so that adding different types of transitions will be fairly easy. As soon as some ideas come to me, I'll probably start doing those.

Second, and more importantly, the README accuses the possibility of a memory leak in the Caveats/Limitations section. As I have said, I couldn't figure out precisely what's causing it.

Now, I haven't actually put a lot of time into this because the smithay-client-toolkit (and wayland-rs in general) is currently getting a large overhaul (see here). In fact, one of the things that have changed is a memory leak in backend-sys. Since we depend on sctk, it is entirely possible that the major changes it is currently going through will cause big changes in our current code as well, so it seems sort of pointless to go crazy with optimizations right now. Furthermore, there is also the possibility that the culprit is actually the image crate. Though, as I've said, I haven't dug deep enough to be sure either way.

The plan is to wait for the sctk version, update the code, and THEN investigate whether or not we have a leak. This issue will be closed once that has been done.

Choose display method for images smaller than your display size

I've noticed that if you display an image that has a lower resolution than your native display res, swww defaults to stretching the image to fill the display. Is it feasible to implement the option to centralize the image instead, filling the border with a color of your choice?

Error: "Failed to connect to socket: Connection refused (os error 111)"

Hello,
Thanks for this application. I installed it according to the readme instruction and added the command "swww init && swww IMG /path/to/image/file" to background command in wayfire.ini. when I logged out and logged in again it didn't work. I separated the two commands and it still did not work.

So I decided to try the command in the terminal and it worked. But after rebooting it didn't work again even in terminal giving the above error message. I can't figure out what went wrong or how to go about debugging.

I also noticed that the error keeps repeated while the command is active. Any help is appreciated.

Thanks

Supporting reading the image from stdin

This is a weird request, but I wish it's possible to do something like this
cat wallpaper.png | swww img -
where - stands for read from standard input as most program do

Question: step, fps and speed.

Hi!

I'm fine tuning an swww integration with sunpaper to allow smooth transitions between time-of-day wallpaper changes. (thank you, btw, this is awesome. I'd previously been using hacky oguri solution for animation that never really worked well)

I'm not sure I fully understand the role of step in the animation process. I'm looking for a sweet spot of longish transition but smooth. Using 3 fps now and 3 step.

Any assistance is appreciated.

swww crashes with HiDPi(aka fractional scaling) in hyprland

           PID: 81438 (swww-daemon)
           UID: 1000 (kyle)
           GID: 985 (video)
        Signal: 6 (ABRT)
     Timestamp: Sat 2023-01-21 09:19:45 CST (2min 36s ago)
  Command Line: swww-daemon
    Executable: /usr/bin/swww-daemon
 Control Group: /user.slice/user-1000.slice/session-11.scope
          Unit: session-11.scope
         Slice: user-1000.slice
       Session: 11
     Owner UID: 1000 (kyle)
       Boot ID: 92700ab9320f43cbb885e4fbeb2564e5
    Machine ID: 0ab96a8a596c4eaab4191e79cb217e43
      Hostname: archlinux
       Storage: /var/lib/systemd/coredump/core.swww-daemon.1000.92700ab9320f43cbb885e4fbeb2564e5.81438.1674263985000000.zst (present)
  Size on Disk: 3.4M
       Message: Process 81438 (swww-daemon) of user 1000 dumped core.
                
                Stack trace of thread 81892:
                #0  0x00007f70feea264c n/a (libc.so.6 + 0x8864c)
                #1  0x00007f70fee52938 raise (libc.so.6 + 0x38938)
                #2  0x00007f70fee3c53d abort (libc.so.6 + 0x2253d)
                #3  0x0000558dc6e81cf7 n/a (swww-daemon + 0x5ecf7)
                #4  0x0000558dc6e81ce6 n/a (swww-daemon + 0x5ece6)
                #5  0x0000558dc6ebcca6 n/a (swww-daemon + 0x99ca6)
                #6  0x0000558dc6ebef0f n/a (swww-daemon + 0x9bf0f)
                #7  0x0000558dc6ebeb84 n/a (swww-daemon + 0x9bb84)
                #8  0x0000558dc6ebeaec n/a (swww-daemon + 0x9baec)
                #9  0x0000558dc6ebeac1 n/a (swww-daemon + 0x9bac1)
                #10 0x0000558dc6e2fdd2 n/a (swww-daemon + 0xcdd2)
                #11 0x0000558dc6e4eb6b n/a (swww-daemon + 0x2bb6b)
                #12 0x0000558dc6e53990 n/a (swww-daemon + 0x30990)
                #13 0x0000558dc6ebf9b5 n/a (swww-daemon + 0x9c9b5)
                #14 0x00007f70feea08fd n/a (libc.so.6 + 0x868fd)
                #15 0x00007f70fef22d20 n/a (libc.so.6 + 0x108d20)
                
                Stack trace of thread 81438:
                #0  0x00007f70fef22356 epoll_wait (libc.so.6 + 0x108356)
                #1  0x0000558dc6e5a6dc n/a (swww-daemon + 0x376dc)
                #2  0x0000558dc6e670f6 n/a (swww-daemon + 0x440f6)
                #3  0x0000558dc6e4a5d3 n/a (swww-daemon + 0x275d3)
                #4  0x0000558dc6e6dd4c n/a (swww-daemon + 0x4ad4c)
                #5  0x00007f70fee3d290 n/a (libc.so.6 + 0x23290)
                #6  0x00007f70fee3d34a __libc_start_main (libc.so.6 + 0x2334a)
                #7  0x0000558dc6e329a5 n/a (swww-daemon + 0xf9a5)
                ELF object binary architecture: AMD x86-64

swww query
(eDP-1: 2133x1199, scale: 2, currently displaying: color: 000)
Scale in Hyprland set to 1.2

[Appreciation] WOW

Hello. Greetings. I have fun using your wallpaper daemon. I can't believe after it caches a 315MB high-quality gif file, it hovers around 15% cpu usage (Yes I know I can use a smaller one like your demo gif so it hovers around 2-8% but still wow). I have submitted this to the openSUSE X11:Wayland repository to share your tool.

Again. Thanks for creating this wonderful tool! 🥳

AUR package

Hi!

I like your software and I had noticed that it didn't have an AUR package.

So I decided to learn how to package software for AUR, I don't know if it is supposed to be done this way but it installs it with completions.

Feel free to mention it in README.md https://aur.archlinux.org/packages/swww

I had enabled notifications for releases, so I can update the package when you release a new version.

Check mime type of picture instead of filename extension

For some reasons we may wish to set wallpapers with no filename extension (for example, I have a script to move wallpaper to ~/.local/share/background ) . However, swww refuses to use such files, throwing Error: "failed to open image '\"/home/aleksana/.local/share/background\"': The image format could not be determined".

In most cases on desktop linux, we do not determine file by its filename extension, but use mine types instead. You can use file --mime-type foo.bar to view a file's type.

Sending wallpapers to the daemon twice in quick succession makes all further respones fail

Using the command below
swww img wallpaper.jpg && swww img wallpaper.jpg

results in error:
Error: "Failed to receive answer: io error: Resource temporarily unavailable (os error 11)"
and higher than normal memory usage sometimes above 200M

after this, using the command
swww kill
then fails with the same error.

I then have to kill the daemon and remove the socket manually.

Removing `/proc` traversal code

I'm talking about is_daemon_running() in src/main.rs. I understand why the daemon check was necessary (I read through #11 and #26), but I think there's a much cleaner solution to this problem: daemons can use inotify to check whether the socket they created has been removed or not. If a running daemon determines that its socket was removed, it should exit immediately. When a new daemon is started, it immediately removes any existing socket file, which will force past daemons (if they exist) to exit. There's a nice Rust crate for using inotify (which is also, quite helpfully, called inotify), and since inotify instances are just file descriptors, they can be inserted into the daemon's main event loop quite easily.

I think this is a better solution because 1) it doesn't require traversing the entirety of /proc whenever the daemon starts up; 2) it allows swww init to deal with possibly-existing daemons better; and 3) it allows the daemon process to detect that its socket file has been removed and to exit accordingly, which it currently does not do. I'm not asking you to implement this feature - I'd quite like to, actually - but I want to confirm that if I do implement it and open an MR for it, it would be accepted.

Separate daemon and client in two separate programs

The idea is to do all the reading, decoding, and resizing of the image in the client, so that the daemon just have to worry about animating it.

Benefits:

  • lower memory usage, since the daemon won't have code it doesn't need (improves #28)
  • isolated dependencies (the daemon won't have to depend on cli, or the image crate, etc. Also, the client doesn't have to depend on smithay)
  • because of this, I will be far less reluctant of allowing some bloat in the client (since it won't contribute to the daemon's memory usage). This would make me far more willing to just allow for more image formats, even if they aren't totally supported upstream (#45).
  • #42 becomes trivial
  • by separating the common code to both programs in a library, we can do stuff like running criterion benchmarks on our compression code (currently I am doing that in a separate, personal project)
  • things will just be more organized in general

Problems: I've tried this a long time ago, but wasn't very familiar with cargo workspaces, which is why I abandoned the idea back then.

  • speed. Last time, the client just too forever to decode and serialize an animated gif, which made it look like the processed hanged.
  • more complex communication. In order for the client to know which size it should resize the image to, it needs to ask the daemon.

The speed problem can be mitigated by first sending just the first frame, and then decoding, compressing, and serializing the rest of the gif's frame, as the daemon plays out the transition animation. Furthermore, we can assure the user the process isn't hanging by printing a progress report, which can be silenced with a --quiet flag. This, of course, comes at the price of even more complex communication between the processes.

Finally, this would represent a big breaking change to all packagers. They would have to rewrite their packaging scripts (which would now install 2 binaries instead of 1). For the end user, things would be more or less the same, swww init would simply call the daemon instead of forking.

Overall, this is very complicated, but I think the benefits are worth it. I will see if I can implement it this December.

Write proper man pages

I've been putting this off long enough. More than one person has had trouble understanding the meaning of --transition-step. We need to have a proper, good explanation for it, in some place where it is easier to read than buried deep inside swww img help.

I believe clap can auto generate man-pages for us. We can try that and see how it goes.

Pre-cache frame of gif

I have a gif which has a ~1min duration, and during this time, the CPU fly at 100%.

Is there a way to pre-cache :

  • load the GIF, cache it in memory, then display it on the screen
    or
  • once the first cache is done, save it as a binary file (or something else), for it to be retrieve next time

I'm unsure about possibilities, but this can avoid my CPU to be 100% at my computer start for~1min

Release build does not work on aarch64 (M1)

First off, great project.

I've been trying to build swww on my M1 Mac running Asahi Linux today but it fails with the following error message in release

Both operands to a binary operator are not of the same type!
  %7198 = xor i64 %7197, i32 4
in function _ZN5image2io14free_functions12load_decoder17h972a54ccb2943d7eE
LLVM ERROR: Broken function found, compilation aborted!

error: could not compile `swww`

Caused by:
  process didn't exit successfully: `rustc --crate-name swww --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=313bff2c136129f8 -C extra-filename=-313bff2c136129f8 --out-dir /home/curtisy/swww/target/release/deps -C strip=symbols -L dependency=/home/curtisy/swww/target/release/deps --extern bincode=/home/curtisy/swww/target/release/deps/libbincode-3471bfd3a21c41ad.rlib --extern clap=/home/curtisy/swww/target/release/deps/libclap-b0083cad16eb3bb1.rlib --extern fast_image_resize=/home/curtisy/swww/target/release/deps/libfast_image_resize-6ffcf43ef1ad24bd.rlib --extern fork=/home/curtisy/swww/target/release/deps/libfork-a88127e95e4d0aac.rlib --extern image=/home/curtisy/swww/target/release/deps/libimage-1be0f6cd5a85dbe3.rlib --extern keyframe=/home/curtisy/swww/target/release/deps/libkeyframe-fa0b216abfb58feb.rlib --extern lazy_static=/home/curtisy/swww/target/release/deps/liblazy_static-3be040a087e9797f.rlib --extern log=/home/curtisy/swww/target/release/deps/liblog-48f21aabe46af05d.rlib --extern lzzzz=/home/curtisy/swww/target/release/deps/liblzzzz-bb8df0835a92e3a7.rlib --extern rand=/home/curtisy/swww/target/release/deps/librand-00b8660841df70ef.rlib --extern serde=/home/curtisy/swww/target/release/deps/libserde-bec4c4a54a6d005a.rlib --extern simplelog=/home/curtisy/swww/target/release/deps/libsimplelog-da9c39d74fa6aed7.rlib --extern smithay_client_toolkit=/home/curtisy/swww/target/release/deps/libsmithay_client_toolkit-1bbbebdc277ae777.rlib -L native=/home/curtisy/swww/target/release/build/lzzzz-ee97ccfbf62b1f56/out -L native=/usr/lib` (exit status: 101)
cargo build --release --verbose  20,552 user 0,091 system 99% cpu (20,677 wasted time).

When I disable lto in Cargo.toml, it seems to be working fine, so it's not a huge issue. Would be great if it worked out of the box though, so I could use the AUR.

If there's anything I can do to help troubleshoot, please let me know.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.