Boomer: a Linux magnifier built on raw X11 and OpenGL

A magnifier that talks to X11 directly instead of through a desktop toolkit

Boomer is a zoomer application for Linux, and the interesting part is what it does not use. It has no dependency on GTK, Qt or any desktop environment toolkit. It talks to the X server and to OpenGL directly, and the README's references section points at an X11 example from the Nim language repository, the Xfwm4 window manager source, the Khronos OpenGL wiki pages for GLX and Xlib, and the X.Org Xextproto documentation for the shared memory extension.

That reference list tells you the architecture. The shared memory extension appears there because of the live update path, and MIT-SHM specifically gets a compile flag of its own. The screenshot related links point at a fast screenshot approach and at xrectsel, the rectangle selection tool, which is the kind of comparison a program that grabs the screen frame by frame would want to make.

The language is Nim, and the build goes through nimble, with a boomer.nimble file at the repository root and the source under src/. The repository is small: a .gitignore, a .travis.yml for CI, a LICENSE, the README, the nimble file, a default.nix, a demo.gif, an overlay directory and src/. That is the whole tree.

The project has an unusual provenance worth noting, since it explains some of the design. The README says development is done on a Twitch channel and links an archive of the streams. The topics list hacktoberfest and hacktoberfest2020. This is a project built in public on stream rather than assembled by a team with a roadmap.

Four development packages, then nimble build

On Debian the dependency list is a single apt-get line, and it is short because there is no toolkit to install:

$ sudo apt-get install libgl1-mesa-dev libx11-dev libxext-dev libxrandr-dev

Four packages, covering the GL headers, the core X11 headers, the Xext extension headers and the RandR extension headers. RandR is the extension that carries screen and monitor geometry, which is what a zoomer needs to know when it scales coordinates.

Building and running takes three commands:

$ nimble build
$ ./boomer --help
$ ./boomer          # to just start using

The binary lands in the working directory as ./boomer, and --help is there because a program that hijacks the screen and the mouse should tell you what it does before it does it.

There is also a config generator, which writes the config file into its default location. The command is `boomer --new-config`, and the file it produces is the one described further down at $HOME/.config/boomer/config.

The NixOS route is documented as well, for people who want the program managed rather than built by hand. The overlay install goes through git clone into a path of your choosing, then a symlink into the nixpkgs overlays directory, then a nix-env install of the nixos.boomer attribute:

$ git clone git://github.com/tsoding/boomer.git /path/to/boomer
$ mkdir -p ~/.config/nixpkgs/overlays
$ cd ~/.config/nixpkgs/overlays
$ ln -s /path/to/boomer/overlay/ boomer
$ nix-env -iA nixos.boomer

The overlay directory in the repository is what makes that symlink work, and the default.nix file at the root is the other half of the Nix build.

The developer build trades a baked binary for live shader reloading

There is a compile-time switch that changes what the program is, and the README is careful about the tradeoff.

Building with the developer flag enables reloading the shaders with Ctrl+R:

$ nimble build -d:developer

For that to work, the shader files frag.glsl and vert.glsl must be in the same folder as boomer.nim. If the shader files are not found, the program will not even start. That is a hard failure rather than a fallback, and the reason is obvious once you understand the mode: the developer build does not bake the shaders into the executable, it loads them from disk at runtime so that an edit can be picked up without a rebuild.

A normal build without -d:developer bakes the shaders into the executable and eliminates the external dependency. The README spells out the conclusion: the developer build is not suitable for day-to-day usage because it creates the external dependency on the shader files.

This is a small design in miniature. A performance oriented program that draws a magnified view of the screen through a shader pipeline needs the shaders to be present at all, and making them compile time constants means one file to ship and no runtime file lookup on the hot path. The developer mode gives up that property in exchange for iteration speed.

Two of the control bindings in the table are specific to this mode. Ctrl+R reloads the shaders and is marked as only for Developer mode, and the ordinary r key reloads the configuration, which works in either build.

Mouse look, scroll zoom and a flashlight, with keys that reset or quit

The control scheme is small enough to memorise in a minute, which is the point for a tool you use while doing something else.

The mouse drives the view. Dragging with the left mouse button moves the image around. The scroll wheel, or the equals and minus keys, zooms in and out, and holding Ctrl while scrolling changes the radius of the flashlight effect. That flashlight is toggled with the f key, and it is a separate visual effect from the zoom rather than part of it.

The keyboard handles the state. The 0 key resets the application state, which the table describes as position, scale, velocity and similar, so a single press returns you to a known starting point instead of leaving you somewhere zoomed into a corner. The q key or ESC quits. The r key reloads the configuration, which is the one you use after editing the config file while the program is running.

The reset behaviour is worth reading carefully, because the description mentions velocity. The program tracks movement with inertia, so it is not just a static pan, and both the drag and the zoom have friction that is configurable.

Two bindings are developer only, Ctrl+R for shader reload. Everything else is available in a normal build.

Four tunables in a plain text config, and three experimental flags

The configuration is a plain text file at $HOME/.config/boomer/config with a simple key equals value format and comment lines:

<param-1> = <value-1>
<param-2> = <value-2>
# comment
<param-3> = <value-3>

Four parameters are supported. min_scale is the smallest the view can get when zooming out. scroll_speed sets how quickly you zoom in and out by scrolling. drag_friction sets how quickly the movement slows down after a drag, and scale_friction sets how quickly the zoom slows down after scrolling.

Those last two are the reason the config exists. The program has inertia in both panning and zooming, and friction decides how quickly that motion decays. A user who finds the default overshoot annoying tunes drag_friction rather than waiting for it to settle.

Separately from the config file, three compile-time flags enable experimental or unstable features, and they are passed to nimble build rather than set in the config.

The live flag turns on live image update, which the README ties to issue 26. The mitshm flag enables a faster live update using the MIT-SHM X11 extension, and it should be used along with live to have any effect. The select flag makes the application let you click on a window to track, so it follows that specific window instead of the whole screen.

Because these are compile flags rather than runtime options, changing one means rebuilding. The config file handles feel, the flags handle behaviour.

Where Boomer is the wrong tool

The first limit is the platform, and it is absolute. Boomer is a Linux X11 application. There is no Windows or macOS support in the repository, and no indication of any being planned. A Wayland session is a different matter: the program talks to X11 directly rather than through a display server abstraction, and while the README does not discuss Wayland at all, which is a reasonable signal that the X11 path is the supported one.

The second is that this is a stream project, not a product. There are no GitHub releases, the repository topics are hacktoberfest and hacktoberfest2020, and the last push was on 2026-05-24. The code is MIT licensed and the dependency surface is tiny, so forking it is entirely reasonable, but nobody is committing to a maintenance schedule, and the README points to a Twitch channel and Patreon for support rather than to an issue tracker policy.

The third is scope. This magnifies the screen. It has no text extraction, no OCR, no colour filters, no high contrast mode and no speech output. If you need magnification with accessibility features, that is a different class of tool and a different project.

What it does offer is unusual: a magnifier with no toolkit dependency, a config file you can edit while it runs, four tunables that actually change how the thing feels, and a NixOS overlay for people who prefer their software declared rather than compiled.

Editorial conclusion

Boomer suits a Linux user who wants a screen magnifier that depends on nothing but X11 and OpenGL, reads a plain text config, and can be installed through a NixOS overlay without pulling a desktop stack in. It does not suit a macOS or Windows user, a Wayland session, or anyone who needs the tool to be maintained to a schedule, since the repository has no GitHub releases and the last push was on 2026-05-24. Before you build it, install the four development packages the README lists, and if you plan to use the developer build, remember that it requires frag.glsl and vert.glsl next to boomer.nim and the program will not start without them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tsoding/boomer on GitHub