LLM Rewrite of the TerminalTextEffects Python A Rust port of the Python TerminalTextEffects (TTE) library, called ttfx, delivers byte-identical frames to the original while starting in ~1 ms versus ~90 ms and achieving a median 9.6× speedup across all 37 effects, according to benchmarks from the project's CI. The parity port, created by Omacom for the Omarchy project, reproduces upstream quirks and is verified against TTE v0.15.0, with two deliberate differences: xoshiro256++ random number generation and no Python plugin support. Terminal text effects as a single static binary. Pipe text in, pick an effect: ls -la | ttfx decrypt cat banner.txt | ttfx beams fortune | ttfx --random-effect git log --oneline -10 | ttfx matrix This is a port of TerminalTextEffects TTE by ChrisBuilds. Every effect, the animation engine, and the command-line interface are their design — this project translates that work to Rust and adds nothing of its own to the art. If you like what you see here, star the original. TTE is MIT licensed and so is this port; the original copyright is preserved in LICENSE /omacom-io/ttfx/blob/master/LICENSE and NOTICE /omacom-io/ttfx/blob/master/NOTICE . Please file effect ideas upstream, where they belong. TTE is a Python package. That's the right call for a library, but for a shell toy that lives in your prompt pipeline it means an interpreter, an install step, and ~90 ms of import before the first frame. ttfx is one dependency-free binary that starts in ~1 ms. That difference is the whole reason this exists. On a fullscreen canvas the heavier effects can't hold a high frame rate under Python: | At 200×50 cells | ttfx | Python TTE | |---|---|---| | beams | 564 fps | 71 fps | | slide | 5,113 fps | 264 fps | | waves | 4,118 fps | 491 fps | | startup | 1.2 ms | 107 ms | Across all 37 effects the median speedup is 9.6× range 4.5×–21.6× . This is a parity port , not a reimplementation-in-spirit. Given the same input, config, and random draws, ttfx produces byte-identical frames to the Python original — verified mechanically in CI against a pinned upstream checkout v0.15.0 , not by eyeballing. | Suite | Checks | What it proves | |---|---|---| tools/parity/run suite.sh | 354 | every effect's frame stream, byte for byte, across configs and seeds | tools/parity/tty compare.sh | 41 | the full terminal byte stream — canvas prep, cursor moves, teardown | tools/tests/cli corpus.sh | 19 | exit codes and stdout/stderr routing | cargo test | goldens + traces | easing/geometry/gradient values and engine state machines | Making that possible meant reproducing upstream's quirks deliberately, not "fixing" them: Python's banker's rounding, gradients built from integer floor division rather than float interpolation, a bezier arc-length approximation that drops its final segment, and looping scenes that report themselves complete on every tick. They're catalogued in plan.md /omacom-io/ttfx/blob/master/plan.md ; the places where Python's unordered iteration had to be pinned down are in . /omacom-io/ttfx/blob/master/docs/ordering-inventory.md docs/ordering-inventory.md Two deliberate differences. Random number generation is not bit-compatible with CPython — ttfx uses xoshiro256++, so --seed is reproducible within ttfx but won't match Python's Mersenne Twister. The parity harness swaps a shared PRNG into both sides, which is what makes frame comparison possible at all. And Python plugin effects aren't supported, since there's no interpreter to load them.