ctx is a 2D vector graphics platform/protocol/library/terminal. With modular
components that can be used to user interfaces ranging from
microcontrollers to desktops.
Features and references
- HTML5 Canvas 2D Context
- Easily bindable C API and protocol builds directly on this standard.
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.
- Small footprint
- Can be tuned for microcontrollers down to ~7kb of RAM + 30kb
of code + 12kb of fontdata, combined with immediate mode UI that can
be re-run, it is sufficient to have a framebuffer covering one
or a few scanlines. More RAM permits more flexible arrangement
of more components using the CTX protocol.
- Portable
- C99 code, with simple make basd build system and
only optional dependencies. It is not a research prototype
relying on vendor specific GPU drivers/frameworks. Within the
architecture of ctx; baking of datastructures for GPU rendering can be
incorporated.
- RGB and CMYK, 8pc and 32bit floating point
-
Supporting RGB332, RGB565 and grayscale + 1bit mode.
With ICC based management of RGB user/device spaces through babl.
- Efficient serializations
- ctx is built around a binary -
and - textual serialization/drawlist of a 2D context.
Thes drawlist representations are used for larger than RAM
framebuffers on microcontrollers, multi threaded cached rendering through
SDL2 and /dev/fb0 backends
and network transparent rendering inside ctx terminal. When
used for graphical clients inside terminals; ctx is even applying
inter-frame compression; reusing frames from the preceding drawlist
by reference.
.
- text rendering
- UTF8 native, there is two font backends
driven by stb_trutetype reading glyph paths on demand from
a TTF/OTF file loaded in RAM/ROM and a native ctx drawlist
representation, separated by '@' define-glyph commands, the
latter provides minimal overhead on micro controllers in
realtime translation of glyph outlines to framebuffer contents.
Shaping is currently limited to horizontal advances +
horizontal kerning, no ligatures.
- VT4xx, ECMA-48
- Almost full vt100 and vt220 escape sequence handling, scrollback, dterm window manipulation (among tabs/clients), bracketed paste, 256 and 24bit colors are supported - as well as a growing subset of vt400 and other relevant terminal escape sequences.
- ametameric palette
- The terminal 16 color palette is optimized for legibility for both trichromats and dichromats
- sixels
- DEC terminal family standard for raster graphics transfer
- kitty graphics
- kitty style raster graphics transfer
- iterm2 inline images
- iterm2 style raster grarphics transfer
- /dev/fb0
- Both ctx as a terminal/platform and
applications built with the ctx library can run
directly on the linux framebuffer without X/wayland, for it to be
fast a fast framebuffer is needed.
- atty
- audio recording and playback (only raw pcm for now, opus codec NYI)
- stb_truetype.h
- If the declarations for stb_truetype are
included before ctx.h - functions to load fonts from TTF/OTF files
become available.
- SDL2
- Optional backend that works better than the framebuffer that gets included when SDL.h is included before ctx.h
- cairo
- support code to render to cairo contexts if cairo.h is included before ctx.h, useful for conformance verfication and SVG and PDF output.
git
Development of ctx happens in a mono-repo, which contains a split up source-tree for the rasterizer/protocol that ends up in the single-header ctx.h files, a tool to generate ctx format subsetted fonts from TTF/OTF files, the sources for a client/terminal multi-plexer - as well as demo applications for the platform.
$ git clone https://ctx.graphics/.git
$ cd ctx.graphics
$ make
Downloads
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.
ctx.h | 760K | The singleheader library ctx. |
ctx-font-regular.h | 128K | Example font to use with ctx, to be a true single header solution - the ascii subset of this is included by default. |
ctx-x86_64-static | 64bit static linux binary - should work in mant distros, but has only DRM, /dev/fb0 and braille rendering not SDL2 |
ctx-i486-static | 32bit static linux binary - should work in mant distros, but has only DRM, /dev/fb0 and braille rendering not SDL2 |
license and funding
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 I want
to relicense the rasterizer and protocol parts of ctx
under the ISC license.
bugs
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 release of ctx - event if the
single header ctx.h already is the rolling release.
- clip does not clip event boxes/shapes
- in_fill is using bounding box - and most reliably works with rectangles.
- radial gradient is only using one center
- dimensions of drop-shadow are not transformed
- miter limit (unless round joins are used, all corners are mitered now)
- cursor keys incorrect (not passing vttest) in vt52 mode
- some form of built in palm supression is desirable in drm/fbdev backend
some potential improvements
- performance (always possible - ctx looks at code/RAM budgets as well)
- continued code refactoring
- glyph fallbacks between fonts
- texture upload as part of terminal protocol
- terminal rewrap on resize
- swap uses of cairo in GEGL with ctx
- 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
- analytical instead of raster clipping
- bindings to a javascript engine like quickjs, for running canvas js content as apps.
- (optional) use of floating point instead of fixed point in rasterizer.
- faster 1d-gaussian blur for shadow blur
- PDF/SVG generation (in addition to existing cairo integration)
- Add API for integrating device-N 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 AVX2 are the only bit
covered thus far, for floating point formats making the
existing code more autovectorizer friendly is a priority.)
- A 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.