rumb

pre-alpha · linux · not your daily driver

An experimental Rust web browser.

Servo renders the page. A vendored slice of Zed's GPUI draws everything around it. Between them, a zero-copy bridge that hands a frame from one GPU context to the other without ever touching the CPU.

read the logbook how it is built

where it is

What works, and what does not

Read this before anything else on the page. rumb is early enough that the second column is the honest half.

rendering

  • Pages render through Servo, one WebView per tab
  • Site coverage is exactly Servo's — GitHub, Discord and plenty of modern CSS still break
  • A tab's device-pixel-ratio is fixed when the tab is built, so a scale change after that stretches the page
  • Video plays through Media Source Extensions, one demux pipeline per source buffer
  • No encrypted media — anything behind DRM does not play at all

input

  • Mouse, scroll and keyboard forwarded into the page
  • Native cursor changes on hover
  • No IME
  • Wheel scrolls glide over the frames that follow instead of landing in one jump

tabs

  • Tab groups with custom colours, and pinning
  • Drag to reorder tabs and whole groups
  • A tab strip on any of the four edges of the window
  • Tab discarding — a sleeping tab drops its WebView

browser chrome

  • URL bar with back, forward and reload
  • Page titles and favicons
  • A DevTools panel driving Servo's own DevTools server
  • A rumb:// start page
  • Fullscreen
  • No bookmarks, no persisted history
  • The chrome's buttons expose a role and a label to assistive technology over AT-SPI
  • The page's own content is absent from that tree, and the chrome has no keyboard navigation

platform

  • Settings persisted to $XDG_CONFIG_HOME/rumb/settings.json
  • No site isolation — Servo runs in-process for embedders
  • Linux only
  • Cookies, the HSTS list and the HTTP cache survive a restart, and a crash mid-write
  • Private browsing exists in the engine as a temporary session and is not wired into the shell

state as of 2026-08-06

what is next

Conditions, not dates

Each item is a direction already decided, with the one thing that has to land first. A trigger can be promised honestly; a quarter would be a guess.

  1. window resize

    A page that keeps its scale when the window's does not.

    Waiting on: a scale factor a WebView can be told about after it is built. Servo takes it once, at construction.

  2. IME

    Composition input, for scripts that need more than one keypress per character.

    Waiting on: a GPUI text-input handler that can hold a preedit, and Servo's IME notifications on the delegate. rumb implements five callbacks; that is not one.

  3. history and bookmarks

    Pages that outlive the process, and somewhere to park a URL.

    Waiting on: a store that appends. rumb persists one file, rewritten whole on every change — wrong shape for a row per navigation. The engine side now does it properly — cookies, the HSTS list and the auth cache written every 30 seconds through a temporary file and a rename — which is the shape the shell still lacks.

  4. site isolation

    One renderer process per origin, so a crashing tab takes only itself down.

    Waiting on: a sandboxed-renderer path in Servo, and a cross-process dma-buf bridge. Tabs landed in June; those two have not.

  5. macOS and Windows

    rumb somewhere other than Linux.

    Waiting on: a per-platform frame export in our Servo fork — IOSurface, or a shared DXGI handle. GPUI is not the obstacle.

how it is built

Two engines, one frame

Servo does not draw to the window. A patch in our fork gives it an offscreen rendering context built from the host's display handle, so it paints into its own framebuffer while GPUI keeps ownership of the drawable the compositor actually sees.

Every frame Servo reports ready is exported as a dma-buf handle — a file descriptor for the GPU memory, plus a fence to say when the writes have landed. GPUI's wgpu backend imports that handle as a texture through the Vulkan HAL and draws it like any other sprite.

The first version did none of that. It read the framebuffer back to the CPU, swapped red and blue, and uploaded the result as an image every single frame. It worked, and it was the wrong shape: a full round trip through system memory for pixels that never left the card.

None of this is secret. The design lives in tramuntana's docs, in the open, because Servo and Stylo are MPL-2.0 and our patches touch their files. The shell — the tabs, the chrome, the compositor bridge on our side — is proprietary.

The fork has since grown past the bridge. Servo now asks the shell about things it used to settle alone: whether a request may leave at all, which user stylesheet and scripts a page gets, whether a webview belongs to a session that leaves nothing behind, who answers when a site asks for a passkey. The logbook has the detail.

the winds

Four points, four forks

"Rumb" is a Catalan nautical term for a compass bearing. Each fork is named after a wind, and the rose is the map: what exists and what is being tried.

  • north

    tramuntana

    live

    Our Servo fork. The frame bridge — an offscreen rendering context, the NVIDIA/EGL WebGL fallback, the dma-buf export — and now the embedder APIs the shell is built on.

  • south

    migjorn

    experimental

    An experimental Servo branch. Where changes go before anyone depends on them.

  • east

    llevant

    live

    Our engine for developers. The fork the developer build is cut from, and where developer-facing work lands first.

  • west

    ponent

    experimental

    Our engine for the business side. It was retired once; the name came back when the business build needed an engine of its own, and it is being tried again rather than depended on.

follow

Where the work happens