Blit module

The blit module provides applications access to blit functionality that's supported by the hardware. It makes use of the hardware to perform blitting operations to reduce CPU loading. The blit module provides a way for applications to blit one image (source) to another (destination). while possibly applying the following transformations.

Blending

Blending of two existing buffers can be carried out by taking the contents of one buffer and overlaying it on top of another buffer at a given level of transparency. The level of transparency to be applied to the input area data is specified by the alpha channel value. The type of transparency can also be selected. The following types are supported:

• SCREEN_TRANSPARENCY_SOURCE

• SCREEN_TRANSPARENCY_TEST

• SCREEN_TRANSPARENCY_SOURCE_COLOR

• SCREEN_TRANSPARENCY_SOURCE_OVER

• SCREEN_TRANSPARENCY_NONE

• SCREEN_TRANSPARENCY_DISCARD

• SCREEN_TRANSPARENCY_REVERSED_TEST

Filling

Hardware often provides an optimized method of filling images with a color. Otherwise, filling is a special case of a scaled blit of a source image with 1x1 pixel dimensions.

Flipping (mirroring)

The source image is horizontally or vertically flipped on the destination image.

Format conversion

This transformation is used when the destination image format is different from the source. For example, a YUYV source is blitted to an RGBA8888 image.

Scaling

Scaling allows the transformation of a source image to a different destination size.

The source and destination buffers are described as rectangular areas, and these input and output areas can be of different sizes, thereby different aspect ratios. The quality of the scaling can be selected where the source and destination buffers differ in size. The scaling qualities that are supported are:

• SCREEN_QUALITY_FASTEST
• SCREEN_QUALITY_NORMAL
• SCREEN_QUALITY_NICEST

with the demand on the GPU increasing as the quality is increased.

Rotation

Rotation is the transformation of the source image onto destination that's rotated by one of the following degrees:

• 90
• 180
• 270

Hardware blitting capabilities vary greatly between platforms. Some transformations may be supported with limitations on some platforms, or they may not be supported at all.

The blit module must define the functions specified in screen/blit.h.

The data required by the composition modules is held in the blit request and the application's context. Access to the data requires a mutex.

The blit module is dependent on the hardware and its supporting libraries.

The blit module sets the global errno variable with the value that corresponds to the error encountered. Some values are defined by POSIX while others are defined by QNX OS. Refer to the QNX OS C Library Reference for details.

Memory consideration for the blit module is mostly platform-dependent. Here are possible situations where the blit module may temporarily allocate memory:

Blit module stores metadata for its own internal use when processing blit requests

This buffer metadata is typically in the range of hundreds or thousands of bytes per buffer (win_handle_t). Blit modules are implemented based on an existing GPU driver API; the memory allocation for metadata is required when handling the translation to the next lower-level API from the blit module.

Blit module requires an auxiliary buffer

Auxiliary buffer space that is proportional to the size of the image in the buffer of the blit request (i.e., win_image_t) may sometimes be required. For example, some GPU drivers require a second buffer for operations that involve rotation, format conversion, or multipass algorithms. Sometimes, more than one such buffer is required so the size of the overhead is the sum of smaller auxiliary buffer sizes. It's possible that the total size of memory required by the auxiliary buffers can exceed the size of the source or destination buffers of the blit request.

Blit module requires command buffers for the GPU hardware

The size of memory that's required for blit requests to the GPU hardware can range between 16k to 128k per blit module context (win_blit_ctx_t).

Blit module defers blit requests

The native blit requests originating from the client (screen_fill() and screen_blit()) may be deferred by the blit module instead of being immediately executed. This deferral enables the GPU hardware to optimize sequences of overlapping operations. The blit module may allocate additional memory to store parameters to each fill and blit call; even more memory may be allocated to analyze and execute these requests during a flush (screen_flush_blits() call).

Any additional memory that is associated with the blit module context (win_blit_ctx_t) or handle (win_handle_t) objects are freed by the blit module as these objects are destroyed.