A reference implementation of the ctx protocol is provided as a single header library, ctx header/library. Interactive Applications written using the C library can run either inside the ctx terminal, or stand-alone using SDL2, fbdev/KMS or in-terminal unicode quads/sextants/ascii as output.

To experiment with ctx, the demo clients included in the source repository is the easiest route, to build the clients as well as the ctx terminal do:

~/src/ $ git clone
Fetching objects: 10294, done.
~/src$ cd
~/src/$ ./
configuration of optional depenencies complete:
    SDL2 yes
    babl yes
    alsa yes
 libcurl yes

Ready to build
~/src/$ make -j10

When done you should be able to run the ctx terminal with

~/src/$ ./ctx

The clients folder contains demo programs and scripts for the terminal.

Running directly with the SDL2 or framebuffer backends has higher performance than going through the terminal abstraction, reducing this gap through tuning and refactoring is a work in progress, for applications the difference between 12fps and 120fps is smaller and small rather than global updates are done.

HTML5 canvas 2D context
Easily bindable C API and protocol building on this standard, along with extensions from SVG. Compositing and blending is according to compositing and blending level 2; ctx goes further than the standard and permits all blending modes to be combined with all compositing modes.
backends: ctx, linux/openbsd KMS, linux/netbsd framebuffer, SDL2, braille
ctx comes with 5 interactive backends, the ctx backend renders the ctx protocol to stdout, and reads input, this provides the client interface for interactive vector clients running in the ctx terminal.
DRM and fbdev backend takes take keyboard input from stdin and tries to read mouse events are from /dev/input/mice. The SDL2 backend permits using ctx clients under wayland/X11 and probably other platforms.
RGB and CMYK, 8pc and 32bit floating point
Supporting RGB332, RGB565 and grayscale + 1bit mode render targets. ICC based color management of RGB user/device spaces through babl as an optional dependency. CMYK colors can be generated on the fly from RGB or set and retained in CMYK mode - when set in CMYK mode the colors correspond directly to the device colors in CMYK mode.

deferred rendering
These drawlist representations are used for scanline/chunk-based rendering on microcontrollers where framebuffer is to large to fit in RAM and tiles and threaded rendering on multi-core systems with SDL2 and /dev/fb0 backends and network transparent rendering inside ctx terminal. Another way to drive larger than RAM is to re-render the frame for each segment instead of buffering it, buffering is however useful when doing networked rendering, ctx can be configured and adapted to deal with a wide range of scenarios. .
text rendering
Three font loading backends, stb_truetype, native-ctx and ctx-fs. The ctx.h header ships with a built-in native-ctx font. In following screenshot a text-file with the commands for the @ glyph is being edited in vim, with instant update across all clients. This massively slows down the UI but not enough to be unusuable. With a simple visual vector editor working directly with the ctx-protocol this provides for an almost complete live font-editor.
The text-shaping is currently limited to horizontal advances + horizontal kerning, no ligatures, RTL or vertical glyph advances - interacting directly with harfbuzz could give us wider support.
DEC terminal family standard for raster graphics transfer
kitty graphics
kitty style raster graphics transfer
iterm2 inline images
iterm2 style raster grarphics transfer
audio recording and playback (only raw pcm for now, opus codec NYI)
If the declarations for stb_truetype are included before ctx.h - functions to load fonts from TTF/OTF files become available.
Optional backend and support code that that gets build when SDL.h is included before ctx.h
support code to render to cairo contexts if cairo.h is included before ctx.h, useful for conformance verfication and SVG and PDF output.

The single header and static binaries for download are autogenerated together with this website each time the git repository is synched.

ctx.h760KThe singleheader library ctx.
git repo
$ git clone
The repository contains the sources for examples and tests, and the implementation of 2D vector rasterization and protocl parser and serializer.
ctx-font-regular.h128KExample font to use with ctx, to be a true single header solution - the ascii subset of this is already defined in ctx.h
ctx-x86_64-static64bit static linux binary - should work in many distros on framebuffer /dev/fb0 and braille backends
ctx-i486-static32bit static linux binary - should work in many distros on framebuffer, /dev/fb0 and braille backends.

Environment variables

Override the backend used for interactive ctx applications, possible values:
auto (default)
try - in order: ctx, SDL2, drm, fb, term
use the ctx protocol, from inside a ctx terminal.
linux DRM
linux framebuffer opening /dev/fb or /dev/fb0
output by converting to terminal graphics, with text at default font size mapped to actual text.
The number of rendering threads to use, defaults to number of cores.
Controls the characters used for drawing in CTX_BACKEND=term mode, possible values:
sextant (default)
use teletext sextant mosaic characters
Use a subset of ascii characters
Use quarter pixels
Use braille characters varying only foreground color
if set to non 0/no always send the full frame instead of optimizing for lower bandwidth usage - should noe be needed apart for debugging.
Visualize which cached pixels are pushed to display
if set to 0 turns off the hash cache - this means that the full frame is rerendered every time, useful to verify if bugs involving non-updating bits of the screen is related to incompleteness of hashing.
if set to 0 turns off the shape caching.
print statistics about hit and miss rate for shape cache

Binary protocol encoding

There is a corresponding binary encoding, considered to be an implementation detail of any given configured build, not a binary exchange format. Where the commands and their arguments are broken down into 9 byte long chunks, where the first byte is the short-form from the table above and parameters are encoded.

future work

pressing issues

The current status of ctx is beyond proof of concept - but still does not fully realize a minimal system demonstrating it's capabilities - some features are also broken and need repair - and for third party use probably more urgently than the following wishlist. When this list is nearing 0 it is time for a tarball/versioned release of ctx. The single header ctx.h linked from this page is a rolling release.

desirable improvements