You heard right, wayfire and other wlroots compositors can now run with vulkan or gles renderers on WSLg (Windows Subsystem for Linux GUI)! Before getting too excited, there is a catch.. it runs entirely in software without a render node, on wlroots headless backend. It is viewable with wayvnc (VNC) or wf-ogon plugin (RDP). This is possible with the advent of the udmabuf allocator in wlroots. It is used in conjunction with llvmpipe to render directly into RAM. The udmabuf allocator is new in latest wlroots, so it has yet to be released. However, I have taken the liberty of backporting the code to wlroots 0.18.2. I have uploaded the code to the udmabuf branch on github here. Without any modifications to wayfire GL code, wayfire runs in software. To do this, the WSL kernel must be compiled with `CONFIG_UDMABUF=y`, since this option is not default. This gives us /dev/udmabuf which key for the functionality needed for userspace dynamically allocated buffers. To get this working, latest mesa 25.x.x is required. Build wayfire with the following:

meson setup -Duse_system_wlroots=disabled -Dwlroots:c_std=c11 -Dwlroots:allocators=gbm,udmabuf --prefix=/usr build
ninja -C build
sudo -E ninja -C build install

and run it with

LP_NUM_THREADS=0 WLR_RENDERER_FORCE_SOFTWARE=1 WLR_BACKENDS=headless wayfire

Don’t forget to load wayvnc in [autostart] section to connect with a vnc client or load the wf-ogon plugin and connect with an rdp client. I didn’t actually try this on WSLg, but I helped those that did get it working. So I don’t have a video of my own, but this is from a user that did run it:

At this point, wayfire has been gaining momentum and the pixdecor plugin is becoming more popular. One unsung hero has been lurking however, and that is the filters plugin. The filters plugin allows a glsl shader to be applied from a file on disk to a window, or the entire screen. It comes with a few shaders to do basic things like CRT effect, color inversion and borders. The borders shader is interesting, since it renders a border of color and width on a window surface. However, with pixdecor shadows, the border doesn’t wrap the decoration, it wraps the outermost part of the shadow region. This is not what we want to happen. Meanwhile, in the CSD (client side decorations) case, the shadow area must be computed to know where to render the border. At first, this task seemed nearly impossible. But for the SSD (server side decorations) case of pixdecor, I was able to side band the shadow margin size to the filters plugin using a globally scoped class, shared between the two out-of-tree plugins. This is as if the class were defined once in a common header. Since no such header exists, we just copy and share it. This happens to work very well and allows filters to get the shadow margin size that pixdecor set. For CSD windows, the filter shader can find the shadow margins easily, with a couple of calls using wayfire’s robust plugin API. After all the rest was ironed out, the results are quite awesome. Here is a basic video to showcase the two plugins working simultaneously.

Here is the pixdecor shade effect with filters plugin:

In this post, we introduce two more animations, shatter and vortex. These two build on the concepts and infrastructure found in the previous animation code. I will focus more on the shatter animation, as it is more technically involving.

Shatter, as you might have guessed from the name, is an animation that fragments the surface into polygons and explodes them into the scene, when closing a window. When opening a window, the reverse implosion is in order. To do this, a way was needed to fragment the rectangular surface into irregular convex polygons. After searching around a bit on the web, I noticed the Voronoi diagrams concept. After learning that boost library offered some useful functions, it was off to test them.

At first, creating a Voronoi diagram was confusing. But after rendering it visually, it started to make sense. Input random points over the surface geometry and get output of convex polygons, suitable for rendering each as a triangle fan. With this in hand, the next step was obvious: rotate the polygons and translate them into an exploding fashion. However there was one small problem. The library doesn’t offer the center point of the polygon, required for rotation. After thinking a bit, I found a simple solution: compute the bounding box of each polygon and take the center of that. This worked remarkably well as it was fast. The only caveat is that the code walk the cells twice, once to get all the points required to know the bounding box and thus center point, and another to use this information when writing the vertices that the shader will use. The first iteration probably can be done once up front at animation creation instead of each frame, but this is yet to be implemented.

Vortex is a fragment shader that sucks the pixels into the center on close and the opposite on open. Now let’s watch some videos!