TICKIT_RENDERBUFFER (7)

NAME

TickitRenderBuffer - store display content to be drawn to the terminal

SYNOPSIS

#include <tickit.h>typedef struct TickitRenderBuffer;

DESCRIPTION

A TickitRenderBuffer instance stores content waiting to be drawn to the terminal. It provides an efficient place to build the eventual display, by applying drawing operations to it that can alter and overwrite the pending content, before eventually flushing it directly to the terminal in an efficient transfer of state. The buffer stores plain text content along with rendering attributes, and also stores line drawing information, allowing line segments to be merged correctly and rendered using Unicode characters.

The primary purpose for the render buffer is the storage of pending content to be displayed. The buffer consists of a grid of cells of the given size. Each cell has a state; neighbouring cells in the same state constitute a region. Each region is either in a skip state (where it will not affect the terminal display when it is flushed), or has either textual content or an instruction to erase the display. In both of these cases, the region has an associated TickitPen instance to give its display attributes. Text regions can be given either by
UTF-8
strings, individual Unicode codepoint numbers, or are created as Unicode line-drawing characters by merging one or more effective line segments.

There are several advantages to using a TickitRenderBuffer over plain drawing requests directly to the terminal. Firstly, because the content is simply stored in memory until it is flushed to the terminal, it doesn't have to be rendered in screen order. It can be built up in any order that makes sense within the application, and when flushed to the terminal it will be performed in an efficient top-to-bottom, left-to-right order.

Secondly, the buffer understands horizontal and vertical line drawing using Unicode characters. While content is being built up, it will keep track of what kinds of lines meet in every cell in the buffer, so that when it is flushed to the terminal it can pick the appropriate Unicode line-drawing characters to render these with.

Thirdly, several features of the buffer are designed to easily support applications that divide the screen area into several possibly-overlapping regions that are managed by different parts of the application. Clipping, translation and masking support the concept of independent areas of the buffer, and stored pens and the state stack support the concept that these areas might be nested within each other, allowing rendering attributes to be inherited from outer regions into inner ones.

VIRTUAL CURSOR

A TickitRenderBuffer instance maintains a virtual cursor position, that application code can use to render at. This is a virtual cursor, because it doesn't relate to the actual cursor in use on the terminal instance; it is simply a position stored by the buffer state.

Most of the content drawing functions come in pairs; one using and updating the cursor position, and a second that operates directly on the buffer contents, without regard to the virtual cursor. Functions of this latter form can be identified by the _at suffix on their name.

PEN

A TickitPen instance can be set on a TickitRenderBuffer, acting as a default pen for subsequent drawing functions. This is optionally combined with a pen instance given to individual drawing functions; if both are present then the attributes are combined, with those of the given pen taking precedence over the ones in the stored pen.

TRANSLATION

A translation offset can be applied to have the drawing functions store their output at some other location within the buffer. This translation only affects the drawing functions; the actual operation to flush the contents to the terminal is not affected.

CLIPPING AND MASKING

All of the drawing functions are also subject to restriction of their output, to apply within a clipping region. Initially the entire buffer is available for drawing, but the area can be restricted to a smaller rectangular area at any time. Requests to draw content outside of this region will be ignored.

In addition to clipping, a buffer can also mask out arbitrary additional rectangular areas within the clipping region. These areas act with the clipping region by ignoring requests to draw inside them while preserving any existing content within them.

Masking and clipping are related but separate concepts. Both place restrictions on where output functions can alter the pending content. Whereas the clipping region is the rectangular area within which all drawing occurs, masking regions are areas in which drawing does not occur.

When combined with translation, these two features allow possibly-overlapping regions of content to be independently managed by separate pieces of code. To render each region of the screen, a render buffer can be set up with a translation offset and clipping rectangle to suit that region, thus avoiding the rendering code having to care about the exact on-screen geometry. By using masking regions, additionally these areas can be managed even when they overlap, by ensuring that areas already drawn by "higher" regions are masked off to ensure that "lower" regions do not overwrite them.

SAVE STACK

As a further assistance to applications wishing to divide the screen area into nested regions, a set of functions exist to store the current auxilliary state of the buffer (that is, all of the mutable attributes listed above, but without the actual pending content) and later restore that state to its original values.

The stored content of a buffer can be copied to another buffer using tickit_renderbuffer_blit(3). This is useful for allowing a window to maintain a backing buffer that can be drawn to at any time and then copied to a destination buffer for display.