The ctx rasterizer/renderer is very compact and strives towards a minimal memory footprint for use on microcontrollers. For the SDL2 and DRM/fbdev backends ctx creates multiple renderer threads by default half the number of available cores - but this can be overriden with the environment variable CTX_THREADS. 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.
The rendering target is split into a grid of 8x8 cells and hashes of the rendering commands affecting each cell are accumulated. Only cells that have changed 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. This type of caching is similar to how react uses a virtual DOM, clients do a full rerender and the system figures out bits to avoid rerendering. A longer writeup of the same idea can be found at cached software rendering page describing a similar implementation in the lite text editor.
As part of constructing a poly-line in the early stages of filling shapes, a hash for the shapes is computed.
For paths with bounding boxes in the range 64x128px to 128x64px, the coverage masks are cached, this caching happens in the buffer-allocator for temporary coverage mask surfaces used when this compile-time option is enabled, when the feature is not enabled with CTX_SHAPE_CACHE in the ctx configuration, the temporary surfaces are not needed as compositing is triggered scanline by scanline. To make use of the shape cache when rendering text. The cache is useful for subsequent frames with updates without scrolling without further adaptations. Using monospace text or snapping text start positions to specific sub-pixel choices, like 1/4 pixels will increase the hit-rate.
For desktop/phone use duplicating the cache for each thread is already a large win. On micro-controllers with RAM left over for caching it can already be useful - but introduces dynamic allocations where ctx could have run without any.
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. (NOTE, as of late june 2021 - these code paths are not active by default - as they reduce latency and some features are unstable with it).
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 the clients implement this policy separately.
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, as well as create unique strings for new frames for video/animations.