Graphics Stack

Introduction

Different STB models have different amounts of memory, some of which is allocated for use as graphics memory. The KreaTV makes it possible to configure the size of the graphics memory partition. To better estimate the amount of required graphics memory, the documentation gives a brief overview of the graphics stack.

The KreaTV uses DirectFB as a graphics subsystem. It allows the allocation and display of images (pixmaps), performs hardware-accelerated graphics operations (such as blitting and scaling), and setup of video layers.

Graphics surface

A surface is an area of graphics memory that corresponds to a rectangular image. These allow the application to directly access the graphics memory and perform various operations such as blits and compositing.

Pixel format

Surfaces may have different pixel formats. Most commonly, KreaTV applications use the following formats:

Name	Abbreviation	Depth per pixel	Used for
Alpha-Red-Green-Blue	ARGB32	4 bytes	Store images and other graphics objects
Color lookup table	CLUT8	1 byte	Store special images with number of colors not greater than 256
Alpha	A8	1 byte	Cache fonts

Buffering

Applications enable double or triple buffering for some surfaces to eliminate tearing and flickering graphics on the screen. It doubles or triples, respectively, the amount of graphics memory used to store those surfaces.

The double buffering technique basically means that drawing operations are performed on a back buffer that is not shown on the display and when an update (flip) is done the previously shown buffer is used as back buffer instead. The triple buffering is similar to double buffering but provides a speed improvement. It is achieved by using an additional back buffer.

A profit of using double or triple buffering very much depends on the application architecture. Enabling buffering cannot be managed via TOI.

For instance, the portal applications usually animate some elements on a page. Thus, the rendering buffer of the portal applications is double buffered. On the other hand, the subtitle renderer application displays static images on the screen, so its rendering buffer does not have a back buffer.

Examples:

• 1280x720 ARGB32 single buffered surface: 1280 * 720 * 1 buffer * 4 bytes = 3,600 KiB
• 1920x1080 CLUT8 double buffered surface: 1920 * 1080 * 2 buffer * 1 byte = 4,050 KiB
• 720x576 ARGB32 triple buffered surface: 720 * 576 * 3 buffer * 4 bytes = 4,860 KiB

Blit operation

Blit is a graphics operation in which an area of a surface is filled by a selected color or copied to another surface. Copying can be done with or without scaling, depending on whether the source and the destination rectangles have the same size or not. Also, both the fill and copy operations can be performed with or without alpha channel blending.

Blitting operations are usually performed by a special hardware component called a blitter. Browser canvas objects and objects participating in CSS animations/transformations are processed through the blitter. Surfaces that are processed through the blitter are stored in graphics memory.

Here you can find preferred practices for the acceleration of CSS transformations in the portal applications.

Compositing

Compositing is the combining of visual elements from separate surfaces into a single surface. The system creates the special double or triple buffered ARGB32 surface for that. It is called "compositing buffer" or "framebuffer" or "display buffer". The graphics surface of each application is composited onto this surface before being displayed on the screen.

The size of the compositor surface can be configured using the compositor_buffer_size parameter.

The buffering mode of the compositor can be configured using the compositor_buffer_mode parameter.

Displaying video is not related to the graphics stack. Graphics and video are mixed by underlying software stack and it is out of scope of this documentation.