## Presentation Device Driver Reference for OS/2

[prev][next][parent][TOC]

### Compressing and Decompressing Data

The bounding routines described above and under Performing the Bounding Accumulation efficiently track the regions on the screen that are updated by Presentation Manager drawing functions. The DCAF-enabled display driver also provides the ability to compress, decompress and, if necessary, convert the format of screen data.

This ability is provided by the following two new entry points or functions :

GetScreenBits

SetScreenBits

The task is performed by the internal routine CompressRect in COMPRESS.ASM. The compressed data that is passed between display drivers uses a private format (that is, no external application or program has the right to examine, alter or make any assumptions about the content of the data). This allows the compression method to be improved in later versions of the driver. Definitions of the data structures are as follows:

1.PACKET HEADER

dd total_data_packet_length (including header)

dw data_format

2.RECTANGLE HEADER

dw xLeft

dw yBottom

dw xRight

dw yTop

3.RECTANGLE DATA

The rectangle data is split into individual rows. Each row is split into run-length encoded blocks (cells), each of which comprises a length field followed by one or more data fields. The sizes of both the length and data fields vary according to the format of the data being transmitted (as specified by the data_format field in the packet header), as follows:

4bpp field size is one byte (8 bits)
8bpp, 16bpp field size is two bytes (16 bits)

The following encoding rules are used:

If the length field contains a positive value (most significant bit not set), then the following single data field is repeated (length) times. If the data field size is 8 bits, this value will be limited to a maximum of 127.

If the length field contains a negative value (most significant bit set), then (length - most significant bit) fields of nonrepeating data follow. If the data field size is 8 bits, this value will be limited to a maximum of 127.

If the length field is zero and the following field is nonzero, the nonzero field is a count of the number of times that the single previous row is repeated. If the data field size is 8 bits, this value will be limited to a maximum of 127. This will only appear as the first cell in a row, and only after there has been at least one row of data.

If the length field is zero and the following field is zero, the next ( third) field is a count of the number of times that the previous pair of rows are repeated. If the data field size is 8 bits, this value will be limited to a maximum of 127. This will only appear as the first cell in a row, and only after there have been at least two rows of data.

The following example shows the hexadecimal values of an 8bpp compressed bitmap:

     0003 0004  00FA 0405 0706 0802 0104 0903 0001  ...........  0000 0003  0000 0000 0004  ...

      lf   df    lf   df   df   df   df   df   df                lf    df    lf   df   df

       cell1                cell2                                 celln      celln+1

This bitmap would expand as follows (two-digit values represent a color index for a single pixel):

     00 04 00 04 00 04 04 05 07 06 08 02 01 04 09 03 00 01 ............ row1

                                                    do three more identical rows (celln):

     00 04 00 04 00 04 04 05 07 06 08 02 01 04 09 03 00 01 ............ row2

     00 04 00 04 00 04 04 05 07 06 08 02 01 04 09 03 00 01 ............ row3

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row4

                                                         do   four   pairs   of   identical   couples   ( celln + 1 ) :

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row5

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row6

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row7

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row8

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row9

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row10

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row11

      00   04   00   04   00   04   04   05   07   06   08   02   01   04   09   03   00   01   . . . . . . . . . . . .   row12

The following example shows the hexadecimal values of a 4bpp compressed bitmap:

     03 04  FA 04 05 07 06 08 02 ...........  00 03  00 00 04  ...

     lf df  lf df df df df df df              lf df  lf df df

     cell1        cell2                       celln  celln+1

This bitmap would expand as follows (one-digit value represents a color index for a single pixel):

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row1

                                          do three more identical rows (celln):

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row2

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row3

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row4

                                          do four pairs of identical couples (celln+1):

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row5

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row6

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row7

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row8

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row9

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row10

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row11

     0 4 0 4 0 4 0 4 0 5 0 7 0 6 0 8 0 2 ............ row12

Standard Golomb Run Length Encoding compression is inefficient at compressing 2x2 dither patterns, which are commonly used by Presentation Manager Display Drivers. The modified compression algorithm handles these patterns efficiently for the following reasons:

For 4bpp and 8bpp, the data field size is such that, when a row is compressed, pairs of adjacent pels are put in each data field. Note that there is no dithering at 16bpp.

When searching for duplicate scanlines, the algorithm also searches for duplicate scanline pairs that will match and compress patterns that repeat on alternate scanlines.

The actual pixel data is stored in Motorola format; that is, the most significant bits of a byte contain the leftmost pels. An example is shown below for a pair of pixels (PEL1,PEL2):

    for the 4bpp format:
                         - PEL1 goes in bits 7..4
                         - PEL2 goes in bits 3..0

    for the 8bpp format:
                         - PEL1 goes in bits 15..8
                         - PEL2 goes in bits  7..0

All 4bpp data is defined as indices into the standard VGA palette. All 8bpp data is defined as indices into the standard XGA palette. All 16bpp data is defined as XGA-format 16-bit color values. (See the appendix regarding default color palettes in the IBM OS/2 Display Device Driver Reference for details of these formats).

All changed drivers must convert their own internal format into one of these standard formats before transmission. Refer to the section on Converting Data later in this chapter.