i like engineering software: interfaces, backend and tools.

resume ↗

r(θ) = ( |cos mθ/4|^n2 + |sin mθ/4|^n3 )^(−1/n1)

40 layers · 150 pts · 6 000 vertices · 702 particles40 layers · 702 particles

drag ↔ twist · ↕ chaos

i like knobs

Symmetrym · lobes

Exponentsn1 · n2 · n3

Morphstar → round

STACK

SURFACE

Noiseamount · seed

Palettestroke color

Highlightring in accent

Chaosgrows upward

LAYER

projects

frixaco/letui

LeTUI

TUI library built from scratch with TypeScript and a Rust core, featuring a component-based API, signal-based state management, CSS-like styling API, a Rust-powered layout and rendering engine, and cell-based diffing.

GitHub↗

frame time · msfull-screen animation · m4 pro115–453 fps · worst → avg

p00.3

p501.9

p954.3

p995.6

max8.7

115–453fps · worst → avg

ts 0.6→ ffi →rust 1.2→sync 0.1→flush 0.3 ms

rusttypescriptbun

frixaco/senmei

original

anime4k

Senmei

In-browser MKV video streamer and player built from scratch, featuring real-time 4K anime upscaling powered by WGSL (WebGPU) shaders ported from Anime4K.

GitHub↗senmei.frixaco.com↗

frame time1080p → 4k · m4 pro

32.3 msper 4k frame

31 fpsmax · film is 24

38 passes3 shaders, sequential

cpu 0.5→upload 4.5→passes 27.3 ms9.4 spare

typescriptwebgpuwgsl

frixaco/xport

Xport

Web app and CLI for exporting X threads, articles, posts, and replies as Markdown or JSON, built around resumable jobs.

GitHub↗xport.frixaco.com↗

@frixaco/xport ↗v0.1.4

0 dependencies · 58.6 kB

lighthousemobile

perf

100

a11y

100

best pr.

100

seo

tanstack startpostgresql

work

full resume (pdf) ↗resume.pdf ↗

2021-present

vbrato, ekko3y 6mo

geoalert7mo

livereach1y 3mo

hitide3mo

moishlem1y 3mo

2020'202021'212022'222023'232024'242025'252026'26

vbrato, ekkomay 2023 - present
Paid music collaborations and song-cover campaigns for artists worldwide. Led frontend and backend development across both products, built the Next.js frontend from scratch, and owned payments, payouts, and mobile audio features. Cut data processing for 1M+ artists from nine days to seven hours and roughly halved Soundcharts costs.
geoalertdec 2022 - jun 2023
AI mapping platform for satellite and aerial imagery. Built high-performance React interfaces for large imagery datasets, simplified component state and data flow, and helped move users to centralized sign-in with zero downtime.
livereachnov 2021 - jan 2023
Social content and analytics platform with shoppable feeds for brands. Led React adoption within an Angular application and improved embedded app performance for e-commerce sites across Europe. Built a custom state manager that cut the JavaScript bundle by 20% and automated package publishing.
hitidedec 2020 - feb 2021
Online clothing brand. Fully automated stock updates with a tested pipeline that transformed Airtable inventory data and stored it in the website's database.
moishlemaug 2020 - oct 2021
Online sports insurance company for individuals, tournaments, etc. Built payment and subscription workflows and internal support tools, redesigned the PostgreSQL schema, and consolidated two backends into one codebase.

blog

Senmei

Watch anime in real time, upscaled to 4K, in your browser.

Senmei is an MKV player built from scratch: a hand-written Matroska parser, WebCodecs decoding, and Anime4K's CNN upscaling shaders ported to WGSL and run on WebGPU every frame.

Quality

The same frame, as decoded (1080p) and after Senmei's Anime4K pipeline (4K). Open each image at full size to compare line work.

Original, 1080p

Original 1080p frame

Senmei + Anime4K, 4K

The same frame upscaled to 4K by Senmei

Features

MKV playback: play/pause, seek, and streaming from a URL over HTTP Range requests
- video: H.264/AVC (8-bit) and HEVC/H.265 (8/10-bit)
- audio: AAC stereo
Real-time upscaling with WebGPU, using a multi-stage, multi-pass render pipeline
Subtitles with positioning and plain text rendering

Performance

Measured on 2026-10-11 on an Apple M4 Pro (Helium, WebGPU on Metal), streaming a 1.44 GB MKV over HTTP Range, 1080p → 4K, 819 frames:

32.3 ms per 4K frame, so 31 fps max (anime runs at 23.976 fps, a 41.7 ms budget)
38 render passes per frame: Clamp Highlights 3, Restore CNN VL 17, Upscale CNN x2 VL 18
27.3 ms in the Anime4K passes, about 4.5 ms uploading the frame, 0.46 ms on the CPU

How it works

Matroska parser (mkv.ts): written by hand, with an API tuned for a video player.
Decoding: WebCodecs VideoDecoder and AudioDecoder.
Upscaling: the WebGPU setup and the Anime4K pipeline are maintained by hand. These Anime4K shaders are ported to WGSL (High-End HQ Mode A preset), in pass order:
1. Anime4K_Clamp_Highlights
2. Anime4K_Restore_CNN_VL
3. Anime4K_Upscale_CNN_x2_VL
4. Anime4K_AutoDownscalePre_x2
5. Anime4K_AutoDownscalePre_x4
6. Anime4K_Upscale_CNN_x2_M
Which passes run depends on the source and output size, following the GLSL !WHEN conditions.
Precision: FP32 shader arithmetic to match GLSL; rgba16float intermediates throughout.
Color: the existing sRGB preview canvas is uploaded, so the original and upscaled views share the same video color conversion. Direct hardware VideoFrame uploads can take a different browser color path. More on handling color space conversion explicitly: https://x.com/wrennly_dev/status/2039326806260748757
Canvas sizing: the real source frame dimensions and the display box are kept separate. A ResizeObserver watches the canvas container, CSS pixels are multiplied by devicePixelRatio for the canvas backing size, CSS aspect-ratio comes from the current video frame or image dimensions, and sizing reruns on resize, fullscreen and DPR changes.

Stack

TypeScript, Vite, Bun
WebGPU, WGSL
WebCodecs
Anime4K

Local development

bun install
bun run dev      # http://localhost:3000
bun run build
bun run preview

TODO

Map //!COMPONENTS 1/2 passes to narrower texture formats instead of rgba16float everywhere.
Play audio through an AudioWorklet instead of scheduling one AudioBufferSourceNode per decoded chunk: the worklet pulls PCM from a reusable buffer on the audio thread, so there are no per-chunk allocations or seams between chunks, pause/seek don't need to tear down a queue, and the played sample position gives a precise clock to sync video to.
Lock-free streaming: one SharedArrayBuffer ring buffer between the network and decoder workers (and the audio worklet), synchronized with Atomics, so nothing is allocated after startup and the GC never runs.
Seek bar previews generated client-side: a second, hidden VideoDecoder fetches (via HTTP Range) and decodes only the keyframe for the hovered timestamp, then scales it down with createImageBitmap.
Adaptive chunk size: measure every fetch, track bandwidth with an exponentially weighted moving average, fetch small chunks just in time on fast connections and buffer more aggressively on slow ones.
Judder-free 23.976 fps on 60/144 Hz displays: schedule each frame for a specific vsync using the audio worklet's sample clock and VideoFrame.timestamp, instead of drawing whenever a frame is ready.

Performance

Measured on 2026-10-11 on an Apple M4 Pro (Helium, WebGPU on Metal), streaming a 1.44 GB MKV over HTTP Range, 1080p → 4K, 819 frames:

32.3 ms per 4K frame, so 31 fps max (anime runs at 23.976 fps, a 41.7 ms budget)

38 render passes per frame: Clamp Highlights 3, Restore CNN VL 17, Upscale CNN x2 VL 18

27.3 ms in the Anime4K passes, about 4.5 ms uploading the frame, 0.46 ms on the CPU

How it works

Matroska parser (mkv.ts): written by hand, with an API tuned for a video player.

Decoding: WebCodecs VideoDecoder and AudioDecoder.

Upscaling: the WebGPU setup and the Anime4K pipeline are maintained by hand. These Anime4K shaders are ported to WGSL (High-End HQ Mode A preset), in pass order:

Anime4K_Clamp_Highlights
Anime4K_Restore_CNN_VL
Anime4K_Upscale_CNN_x2_VL
Anime4K_AutoDownscalePre_x2
Anime4K_AutoDownscalePre_x4
Anime4K_Upscale_CNN_x2_M

Which passes run depends on the source and output size, following the GLSL !WHEN conditions.

Precision: FP32 shader arithmetic to match GLSL; rgba16float intermediates throughout.

Color: the existing sRGB preview canvas is uploaded, so the original and upscaled views share the same video color conversion. Direct hardware VideoFrame uploads can take a different browser color path. More on handling color space conversion explicitly: https://x.com/wrennly_dev/status/2039326806260748757

Canvas sizing: the real source frame dimensions and the display box are kept separate. A ResizeObserver watches the canvas container, CSS pixels are multiplied by devicePixelRatio for the canvas backing size, CSS aspect-ratio comes from the current video frame or image dimensions, and sizing reruns on resize, fullscreen and DPR changes.

TODO

Map //!COMPONENTS 1/2 passes to narrower texture formats instead of rgba16float everywhere.

Play audio through an AudioWorklet instead of scheduling one AudioBufferSourceNode per decoded chunk: the worklet pulls PCM from a reusable buffer on the audio thread, so there are no per-chunk allocations or seams between chunks, pause/seek don't need to tear down a queue, and the played sample position gives a precise clock to sync video to.

Lock-free streaming: one SharedArrayBuffer ring buffer between the network and decoder workers (and the audio worklet), synchronized with Atomics, so nothing is allocated after startup and the GC never runs.

Seek bar previews generated client-side: a second, hidden VideoDecoder fetches (via HTTP Range) and decodes only the keyframe for the hovered timestamp, then scales it down with createImageBitmap.

Adaptive chunk size: measure every fetch, track bandwidth with an exponentially weighted moving average, fetch small chunks just in time on fast connections and buffer more aggressively on slow ones.

Judder-free 23.976 fps on 60/144 Hz displays: schedule each frame for a specific vsync using the audio worklet's sample clock and VideoFrame.timestamp, instead of drawing whenever a frame is ready.