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/DRM 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 https://ctx.graphics/.git/
Fetching objects: 10294, done.
~/src$ cd ctx.graphics/
configuration of optional depenencies complete:
Ready to build
~/src/ctx.graphics$ make -j10
When done you should be able to run the ctx terminal with
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, DRM, fbdev, 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
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
- 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.h||760K||The singleheader library ctx.|
$ git clone https://ctx.graphics/.git
The repository contains the sources for
examples and tests, and the
implementation of 2D vector rasterization
and protocl parser and serializer.
|ctx-font-regular.h||128K||Example 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-static||64bit static linux binary - should work in many distros on framebuffer /dev/fb0 and braille backends|
|ctx-i486-static||32bit static linux binary - should work in many distros on framebuffer, /dev/fb0 and braille backends.|
- Override the backend used for interactive ctx applications,
- 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
- Controls the characters used for drawing in CTX_BACKEND=term mode,
- 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.
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.
- configure fonts
- use separate configured fonts for mono/italic/bold
(keeping current fallback synthesizing code)
- clip does not clip event boxes/shapes
- in_fill is using bounding box
- radial gradient is only using one center
- dimensions of drop-shadow are incorrectly transformed
- miter limit (unless round joins are used, all corners are mitered now)
- square line ends
- palm supression during typing in drm/fbdev backend
- Key-event confusion when changing keyboard layouts
- performance, there always seem to be room for improvement.
- continued code clean-ups and refactoring, making non-amalgated build work
- glyph fallbacks between fonts
- analytical instead of raster clipping.
- RTL text
- color emoji, the font format supports it, font fallback needs improvement as well as support for double-width.
- double-width glyphs (terminal) - for non-terminal use this works, for emoji and asian scripts
- multi-head, both for DRM when plugging in HDMI/VGA and networked
connect to ESP32 / html5 canvas clients.
- swap some uses of cairo in GEGL with ctx, pass ctx data
as buffers, or have ctx backed buffers in GEGL.
- binary search for glyphs in ctxf font backend, making it scale well for wide unicode coverage.
- websockets + js + HTML5 Canvas renderer/client for protocols
- wayland/libinput support
- optional use of floating point instead of fixed point in rasterizer.
- faster and correctly transformed 1d-gaussian blur for shadow blur
- PDF/SVG generation (in addition to existing cairo integration)
- Add API for integrating device-N and spectral with RGB/CMYK through coloritto
- 32bit float coverage from rasterizer - right now we support 32f images/color; but composite using 8bit alpha masks.
- More SIMD code (the common RGBA8 cases for handled as manual
simulated 64bit SIMD and AVX2 are the only bits covered thus
far, for the floating point formats making the existing code more
autovectorizer friendly is a priority.)
- GPU renderer, the information needed for precomputation and
spatial organization in many GPU rendering approaches is already
present - alternatively backends sitting on top of exisitng
libraries like NanoVg.