I am proud to announce awww can now idle at just around 230 Kb in my machine using the no-libc-daemon branch (note: we need some magical incantions to make the code compile in that branch, so compile the daemon using the build-daemon.sh script, and then compile the client separately with cargo build --package awww --release):
But wait! What's that 19350Kb buffer we are allocating? That's the buffer we memory map to load the initial image, which we promptly unmap after we are done setting the wallpaper, and thus its cost disappears.
The no-libc-daemon branch implementation unfortunately currently only works on Linux machines. If you are on another Unix, you can still use the main branch, which will idle at around 2.3 Mb (about 10x as much, but still much lower than pretty much every other wallpaper setter for wayland I know of).
I have always been fascinated by projects like min-sized-rust, trying to create small Rust executables, or the famous post A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux , which walks us through the creation of a 45 byte executable Linux binary. However, these posts often have small practical applicability, since people will usually not go through the trouble of using any of their techniques, because they would be too taxing, impractical, or error-prone. For example, one of min-sized-rust's recommendations is to avoid all formatting, as Rust's core::fmt includes a lot of code in the final binary. While this is certainly true, how many of us are willing to let go of runtime formatting? It would imply, at least, using static strings for all debugging, logging, error reporting and user interfaces. Essentially impossible for many projects.
I am the creator and maintainer of a somewhat popular wayland wallpaper manager: swww. swww has two killer features:
gifs or animated pngsWhen I first created it, these things did not really exist in the wayland ecosystem. Stuff like swaybg, despite being very well built, only support setting a single wallpaper on startup. This means, if you want to change the wallpaper during runtime, you must pkill the daemon, and then start it again. This led to your background being completely dark during the in-between time while you restarted the daemon. Even a script automating the process could still have a quick flash, and even if it didn't, it still made the transition seem very abrupt. So swww allows you to change that at runtime, with a nice-looking transition animation that's quite pleasant.
Regarding animated wallpapers, mpvpaper existed before swww, and it works quite well if you want to use video as your wallpaper. Unfortunately, I found it to consume far too much CPU and RAM when I used it for simple animated images. At the time, I had a dual monitor setup, and I had to fire up one mpvpaper instance per monitor, which made it use quite a bit of resources. swww does not support video, but it is far better at using animated images like gifs and apngs.
I am in the process of writing a bunch of applications for my desktop environment. The plan is to have, at a minimum:
Obviously I am aware the terminal will probably take very long, but I plan on working on it little by little over a long time. These applications are not meant for anything other than my own personal use, but if you would like to accompany their development, just have a look at this repository.
In any case, all the above applications require text rendering, which is in itself a big can of worms. We will ignore all of that and instead focus only on the final step: alpha blending the glyph's grayscale bytemap onto a background.
Alpha blending two 8bit values using an 8bit alpha channel can be done like so:
fn alpha_blend_with_float(dst: &mut u8, src: u8, alpha: u8) {
// put alpha in 0..1.0 range
let a = alpha as f32 / 255.0;
// get the complement
let ac = 1.0 - a;
// multiply each component by how much they should
// "contribute" to the final value
*dst = ((*dst as f32 * ac) + (src as f32 * a)).round() as u8;
}