darmanandClaude Opus 5
74ec7c89f0
ChromePassElement::draw() rounded its device-space box with CBox::round(), which derives the size from the two rounded corners - round(x + w) - round(x) - making the rounded width and height a function of the *position's* fractional part. A box merely sliding at a constant size therefore has its size flip by a pixel every few frames. Every one of those flips misses the cachedTexSize check in GetBorderTexture, GetShadowTexture and GetTitleTexture alike, and each miss is a full cairo re-render plus a fresh GPU texture allocation and upload for content that did not change appearance at all. That is exactly what a workspace switch, a window move, or any other position-only animation does - every frame, for every window on screen - and it is why those animations stutter. Measured against hyprutils, a sliding window resized nothing yet rebuilt its textures on 18-40% of frames at scale 1.0/1.25/1.5/1.6 (integer scales happened to be stable); rounding the size on its own takes all of those to zero. What round()'s coupling buys is a far edge landing on the same device pixel as an adjacent box's near edge. Nothing abuts this box - it is a free-floating decoration drawn over everything - so there is no seam here to keep closed. damageEntire() gains a one-pixel margin to match: with position and size now rounded separately, the drawn box's far edge can land up to a device pixel past where the logical damage box scales to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hypr-chrome
A Hyprland plugin that draws a chamfered HUD-style border frame behind each window, expanded past the window's own edges, with a floating title bar hanging off the top-left corner. The frame's corners are chamfered by an amount inferred from the window's own border rounding, so the border peeking out around a rounded window's corners reads as a matching diagonal cut rather than a hard rectangular corner. Border color tracks Hyprland's own active/inactive border color live, gradients included.
Config
plugin {
hyprchrome {
enabled = true # bool
extent = 12 # int, px the border extends past the window edge
follow_hyprland_border_color = true # bool, use Hyprland's own active/inactive border color instead of active_color/inactive_color below
active_color = 0xFFD063FF # focused-window border color, used when follow_hyprland_border_color is false
inactive_color = 0xFF6C6C6C # unfocused-window border color, used when follow_hyprland_border_color is false
titlebar_height = 8 # int, px height of the floating title bar
titlebar_text_size = 12 # int, px font size of the title bar's text
titlebar_font = sans-serif # string, passed to cairo_select_font_face
}
}
active_color/inactive_color take the same syntax as Hyprland's own
general:col.active_border — a single color, or several plus an optional
angle for a gradient:
active_color = rgba(ff0000ff) rgba(00ff00ff) 45deg
Installing
hyprpm add https://git.mgaction.town/darman/hypr-chrome.git
hyprpm enable hypr-chrome
hyprpm builds the plugin from source against your own installed Hyprland,
using the build commands declared in hyprpm.toml (the same cmake
invocations as below).
NixOS
flake.nix exposes packages.x86_64-linux.default, built against
pkgs.hyprland from this flake's own nixpkgs input (with Hyprland's own
compiler/stdenv, for ABI correctness). Add this repo as a flake input and
set inputs.hypr-chrome.inputs.nixpkgs.follows = "nixpkgs" (your own
system's nixpkgs input) so it's built against the exact Hyprland your
system runs - then add inputs.hypr-chrome.packages.${system}.default
directly to your wayland.windowManager.hyprland.plugins
(NixOS/home-manager) list. The package installs as lib/libhypr-chrome.so
(the lib<pname>.so convention that module derives its path from
automatically) even though the plain hyprctl/hyprpm path above uses
the unprefixed hypr-chrome.so.
Building
Requires the Hyprland headers/libs (hyprland, libdrm, libinput,
libudev, wayland-server, xkbcommon, pixman-1, cairo, etc.), ABI-locked
to the exact Hyprland build you'll load the plugin into. A pinned Nix flake
dev shell provides all of it:
nix develop
cmake -B build -S .
cmake --build build
This produces hypr-chrome.so at the repo root (not inside build/, so the
hyprctl/buildAndLoad.sh commands below can find it directly).
Developing
Load/reload the plugin into a running Hyprland session:
hyprctl plugin load "$(pwd)/hypr-chrome.so"
hyprctl plugin unload "$(pwd)/hypr-chrome.so"
buildAndLoad.sh chains build + reload for iteration. Hyprland's plugin
loader never fully unmaps a .so once dlopen'd, so reloading the same path
just re-serves the old (possibly stale) mapping — the script works around
this by copying each build to a uniquely-suffixed filename before loading it
and cleaning up prior copies. It also unloads any copy your own Hyprland
config loads (found by grepping $XDG_CONFIG_HOME/hypr for a hypr-chrome
.so path), since that one is a separate dlopen that would draw a second
frame on every window. It hardcodes an absolute checkout path at the top;
check it matches your checkout before running it.