ctx caching and threading

The core of ctx rendering is the rasterizer which is written to be compact enough for rendering on microcontrollers. There is nothing shared between the rasterizers, they have their own gradient and shape-cache (explained below) and do fully independent read-only, lock-free rasterization from a shared drawlist and textures. For the SDL2 and DRM/fbdev backends a set of rendering threads from the environment variable CTX_THREADS or by default half the number of available cores.


The rendering target is split into a 8x8 grid and in-parallell for the grid cells hashes are computed for intersecting painted areas. Only cells that change from the preceding frame are queued for rendering in threads. This way most contents can remain unchanged when all that is happening is editing of text in a terminal shell or editor. A longer writeup of the same idea can be found at cached software rendering page describing a similar implementation in the lite text editor.

shape cache

As part of constructing a poly-line in the early stages of filling shapes, a hash is computed using position and coordinates of commands multiplied with some primes.

For paths with bounding boxes in the range 64x128 to 128x64px, the coverage masks are cached. ctx text glyphs are redrawn from curves on each instantiation the shape cache transparantly matches some of the reused glyphs when rendering covering subpixel positioning, rotations and scale transparently; also other shapes that were not glyphs are chaught and reused by the same mechanism. The shape cache makes rasterizing a large set of filled arcs with a small set of radiuses fast, as many of the subpixel positions are reused.

A todo item for the shape-cache is tuning it to be usable on microcontollers. For desktop/phone use duplicating the cache for each thread is much larger win than performance hit due to overhead, but simplifications making it usable with more constrained RAM and no allocations would also benefit these cases.

inter-frame protocol compression

Applications the use ctx as a libary can either directly run with the above mentioned SDL2, DRM or fbdev backends - or they can run as clients inside the ctx terminal and window manager. When running as clients, the HTML5 2D Context is serialized in compact form using the ctx protocol. When transmitting the commands for the current frame, the ctx terminal permits reuse of segments of data from the previous frames raw data as a form of compression. Avoiding global absolute coordinates when drawing by using relative coordinates and/or transforms can be used to optimize data. This caching permits complex immediate mode UIs to be updated over a low-bandwidth link.

Texture caching

The caching scheme used by ctx dictates that textures are valid for reuse in the current frame and if the texture was used in the previous frame. The client and rasterizer both implement this policy separately. For embedded hosts, bitdepth reduction to RGB332 and/or resizing is planned to degrade somewhat gracefully under memory pressure.

When providing a NULL eid, to define_texture, the sha1 of the pixeldata is computed. If the eid was already registered and valid, we stop here and issue a ctx_texture call instead - thus client code that knows eids can always use define_texture without overhead.