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:

• 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.

  ---

  [Back: Accumulating and Querying Screen Bounds]
  [Next: Maintaining and Tracking Screen Change Areas (SCAs)]