GLsizei height, GLenum format, GLenum type, const GLvoid *pixels )
eqn not supported
Several parameters define the encoding of pixel data in memory and control the processing of the pixel data before it is placed in the frame buffer. These parameters are set with four commands: glPixelStore, glPixelTransfer, glPixelMap, and glPixelZoom. This reference page describes the effects on glDrawPixels of many, but not all, of the parameters specified by these four commands.
Data is read from pixels as a sequence of signed or unsigned bytes, signed or unsigned shorts, signed or unsigned integers, or single-precision floating-point values, depending on type. When type is one of GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, or GL_FLOAT each of these bytes, shorts, integers, or floating-point values is interpreted as one color or depth component, or one index, depending on format. When type is one of GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_SHORT_5_6_5, GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_10_10_10_2, each unsigned value is interpreted as containing all the components for a single pixel, with the color components arranged according to format. When type is one of GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_2_10_10_10_REV, each unsigned value is interpreted as containing all color components, specified by format, for a single pixel in a reversed order. Indices are always treated individually. Color components are treated as groups of one, two, three, or four values, again based on format. Both individual indices and groups of components are referred to as pixels. If type is GL_BITMAP, the data must be unsigned bytes, and format must be either GL_COLOR_INDEX or GL_STENCIL_INDEX. Each unsigned byte is treated as eight 1-bit pixels, with bit ordering determined by GL_UNPACK_LSB_FIRST (see glPixelStore).
width$~ times ~$height pixels are read from memory, starting at location pixels. By default, these pixels are taken from adjacent memory locations, except that after all width pixels are read, the read pointer is advanced to the next four-byte boundary. The four-byte row alignment is specified by glPixelStore with argument GL_UNPACK_ALIGNMENT, and it can be set to one, two, four, or eight bytes. Other pixel store parameters specify different read pointer advancements, both before the first pixel is read and after all width pixels are read. See the glPixelStore reference page for details on these options.
The width$~ times ~$height pixels that are read from memory are each operated on in the same way, based on the values of several parameters specified by glPixelTransfer and glPixelMap. The details of these operations, as well as the target buffer into which the pixels are drawn, are specific to the of the pixels, as specified by format. format can assume one of 13 symbolic values:
Each fixed-point index is then shifted left by GL_INDEX_SHIFT bits and added to GL_INDEX_OFFSET. If GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result.
If the GL is in RGBA mode, the resulting index is converted to an RGBA pixel with the help of the GL_PIXEL_MAP_I_TO_R, GL_PIXEL_MAP_I_TO_G, GL_PIXEL_MAP_I_TO_B, and GL_PIXEL_MAP_I_TO_A tables. If the GL is in color index mode, and if GL_MAP_COLOR is true, the index is replaced with the value that it references in lookup table GL_PIXEL_MAP_I_TO_I. Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with $2 sup b -1$, where $b$ is the number of bits in a color index buffer.
The GL then converts the resulting indices or RGBA colors to fragments by attaching the current raster position z coordinate and texture coordinates to each pixel, then assigning $x$ and $y$ window coordinates to the $n$th fragment such that
where ($x sub r , y sub r$) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
Each fixed-point index is then shifted left by GL_INDEX_SHIFT bits, and added to GL_INDEX_OFFSET. If GL_INDEX_SHIFT is negative, the shift is to the right. In either case, zero bits fill otherwise unspecified bit locations in the result. If GL_MAP_STENCIL is true, the index is replaced with the value that it references in lookup table GL_PIXEL_MAP_S_TO_S. Whether the lookup replacement of the index is done or not, the integer part of the index is then ANDed with $2 sup b -1$, where $b$ is the number of bits in the stencil buffer. The resulting stencil indices are then written to the stencil buffer such that the $n$th index is written to location
where ($x sub r , y sub r$) is the current raster position. Only the pixel ownership test, the scissor test, and the stencil writemask affect these write operations.
The GL then converts the resulting depth components to fragments by attaching the current raster position color or color index and texture coordinates to each pixel, then assigning $x$ and $y$ window coordinates to the $n$th fragment such that
where ($x sub r , y sub r$) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
If GL_MAP_COLOR is true, each color component is scaled by the size of lookup table GL_PIXEL_MAP_c_TO_c, then replaced by the value that it references in that table. c is R, G, B, or A respectively.
The GL then converts the resulting RGBA colors to fragments by attaching the current raster position z coordinate and texture coordinates to each pixel, then assigning $x$ and $y$ window coordinates to the $n$th fragment such that
where ($x sub r , y sub r$) is the current raster position. These pixel fragments are then treated just like the fragments generated by rasterizing points, lines, or polygons. Texture mapping, fog, and all the fragment operations are applied before the fragments are written to the frame buffer.
The following table summarizes the meaning of the valid constants for the type parameter:
| Type Corresponding Type |
| GL_UNSIGNED_BYTE unsigned 8-bit integer |
| GL_BYTE signed 8-bit integer |
| GL_BITMAP single bits in unsigned 8-bit integers |
| GL_UNSIGNED_SHORT unsigned 16-bit integer |
| GL_SHORT signed 16-bit integer |
| GL_UNSIGNED_INT unsigned 32-bit integer |
| GL_INT 32-bit integer |
| GL_FLOAT single-precision floating-point |
| GL_UNSIGNED_BYTE_3_3_2 unsigned 8-bit integer |
| GL_UNSIGNED_BYTE_2_3_3_REV unsigned 8-bit integer with reversed component ordering |
| GL_UNSIGNED_SHORT_5_6_5 unsigned 16-bit integer |
| GL_UNSIGNED_SHORT_5_6_5_REV unsigned 16-bit integer with reversed component ordering |
| GL_UNSIGNED_SHORT_4_4_4_4 unsigned 16-bit integer |
| GL_UNSIGNED_SHORT_4_4_4_4_REV unsigned 16-bit integer with reversed component ordering |
| GL_UNSIGNED_SHORT_5_5_5_1 unsigned 16-bit integer |
| GL_UNSIGNED_SHORT_1_5_5_5_REV unsigned 16-bit integer with reversed component ordering |
| GL_UNSIGNED_INT_8_8_8_8 unsigned 32-bit integer |
| GL_UNSIGNED_INT_8_8_8_8_REV unsigned 32-bit integer with reversed component ordering |
| GL_UNSIGNED_INT_10_10_10_2 unsigned 32-bit integer |
| GL_UNSIGNED_INT_2_10_10_10_REV unsigned 32-bit integer with reversed component ordering |
The rasterization described
so far assumes pixel zoom factors of 1. If
glPixelZoom is used to change the $x$ and $y$ pixel zoom factors, pixels
are converted to fragments as follows. If ($x sub r$, $y sub r$) is the
current raster position, and a given pixel is in the $n$th column and $m$th
row of the pixel rectangle, then fragments are generated for pixels whose
centers are in the rectangle with corners at
where $zoom sub x$ is the value of GL_ZOOM_X and $zoom sub y$ is the value of GL_ZOOM_Y.
GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, and GL_UNSIGNED_INT_2_10_10_10_REV are only valid for type if the GL version is 1.2 or greater.
GL_INVALID_ENUM is generated if format or type is not one of the accepted values.
GL_INVALID_OPERATION is generated if format is GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_RGBA, GL_BGR, GL_BGRA, GL_LUMINANCE, or GL_LUMINANCE_ALPHA, and the GL is in color index mode.
GL_INVALID_ENUM is generated if type is GL_BITMAP and format is not either GL_COLOR_INDEX or GL_STENCIL_INDEX.
GL_INVALID_OPERATION is generated if format is GL_STENCIL_INDEX and there is no stencil buffer.
GL_INVALID_OPERATION is generated if glDrawPixels is executed between the execution of glBegin and the corresponding execution of glEnd.
GL_INVALID_OPERATION is generated if format is one GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, of GL_UNSIGNED_SHORT_5_6_5_REV and format is not GL_RGB.
GL_INVALID_OPERATION is generated if format is one of GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, or GL_UNSIGNED_INT_2_10_10_10_REV and format is neither GL_RGBA nor GL_BGRA.