ctx is a configurable and lightweight 2D vector graphics stack with focus on remote and deferred rendering building on top of the HTML5 canvas 2D context specification. The project provides as single header library which implements both a binary and textual drawlist protocol. The ctx single-header library provides APIs for registering keybindings and pointer events with callbacks in user-relative coordinates. Events and rendering are abstracted for linux framebuffer, SDL2, braille in terminal and running in the ctx terminal. The ctx terminal is the binary built in the toplevel of a ctx git checkout. This terminal serves as a demanding example for app-development with ctx, it used to be faster - but peformance of minimal framebuffer touching has been replaced with well-formed vector output - for /dev/fb0 usage fbterm is a *lot* faster - but lacks the richer media of ctx, which permits the terminal to run inside itself with minimal overhead. From within the terminal even shell scripts get the ability to render vector graphics.
There are extensions for sending raster graphics with terminals, ranging from sixels through iterm2 base64 upload to kitty - that permit uploading buffers. With the increased pixel density of modern displays sending full framebuffers over the wire is too expensive for updating a buffer. WARNING: ctx is a work in progress, some terminal interactions are wonky - and display latency is good only for localized changes like text editing - global scrolling works less well, ctx is also relying on stb_image for image decoding support as well as providing in-band access to your microphone.
When programming in DOS or with SVGAlib the mono-spaced text rectangle can be upgraded to graphics mode. Similarly terminals have also not only provided a grid of monospaced text. Examples are DECs VTs with ReGIS, tektronix, BBSs with RIPscript and in some ways Display PostScript and NEWS.
The ctx parser in the terminal that clock.sh creates a binary in-memory dawlist. This drawlist is played back in-place during the drawing commands used to draw the terminal with ctx. The terminal and its clients are thus merged into a single drawlist - which can include multiple tabs/windows.
The single drawlist is used for read-only access by independent worker-threads. The framebuffer to update is split into a grid (of at least 4 by 4) where each cell is a render job. Hashes of the drawlist are computed in parallel for all cells - and the cells where the hash differs from the last update are spread among the render threads. This permits for low latency updates for small changes, it is less optimal for fullscreen scrolling of large buffers. A cache that captures the rasterization of smallish shapes is currently disabled, since it glitches under threading - disabling it has the advantage of the threads being fully independent.
One of ctx' backends in addition to SDL2 and linux framebuffer is the ctx backend which outputs the ctx protocol on stdout and accepts keyboard/pointer input either as standard terminal escape sequences or in a passthrough mode of ctx' own event format, inherited from microraptor gui. Pointer events can be handled as global events like the ones delivered to the canvas element in HTML. But a better abstraction can be event callbacks registered for the active path under the current transform. Ctx maintains a list of these in draw order and examines them from to back for bounding box (and NYI inPath) and delivers events - with the ability to stop propagation when a later registered handler wants to override earlier registered ones.
Sending full frames of vectors becomes bandwidth intensive with complex interfaces, this will be remediated by reusing ranges from the previous frames bytestream, this is currently not implemented but will provide signficant bandwidth savings.
ctx is a work in progress and there is known bugs, on one important ergonomic measure, in this regard ctx seem to already be competetive with GPU accelerated terminals. Due to how framebuffer caching is done latency is higher with large updates and scrolling than without. It still is almost nice enough for the main author to be configured as his systems default terminal - but not quite.
The benchmarks to the right are shown in typometer, a utility to measure time from keyboard event to display update. The benchmarks have been done under the Xorg session with openbox on a debian system. ctx is using the SDL2 backend and is thus having higher overhead than should be neccesary using a more dedicated backend.
The measurements to the right are done under an xorg session of GNOME, the extra steps of compositing does increase latency somewhat.
There is no tarball releases yet, but the development version can be cloned and contains some example/test clients in C and bash, if you've got the development headers for SDL2 the following builds a ctx binary.
$ git clone https://ctx.graphics/.git $ cd ctx.graphics $ make
|ctx.h (browse)||580K||The singleheader library ctx.|
|ctx-font-regular.h (browse)||128K||Example font to use with ctx|
|ctx-x86_64-SDL2||ELF 64bit binary for linux dynamically linked against SDL2, should work in most distros.|
|ctx-x86_64-SDL2-AVX2||ELF 64bit binary for linux dynamically linked against SDL2, should work in most distros but requires a cpu with AVX2 instructions.|
|ctx-x86_64-static||64bit static linux binary - should work in more distros, but has only /dev/fb0 and braille rendering.|
|ctx-i486-static||32bit static linux binary - should work in more distros, but has only /dev/fb0 and braille rendering.|
The terminal is available under GPLv3+, and ctx.h is available under LGPLv3+ you can encourage continued development of ctx and dissimilar technologies by financially supporting me, Øyvind Kolås who is doing independent pro-bono R&D through patreon and similar. If my income through such sources is above 4000USD per month for a year, or a similar amount in shorter time the protocol and rasterizer parts of ctx will be relicensed under the ISC license.
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 morge urgently than the following wishlist. When this list is nearing 0 it is time for a tarball release of ctx - event if the single header ctx.h already is the rolling release.