GLint y, GLsizei width, GLsizei height, GLenum type )
eqn not supported
x and y specify the window coordinates of the lower left corner of the rectangular region to be copied. width and height specify the dimensions of the rectangular region to be copied. Both width and height must not be negative.
Several parameters control the processing of the pixel data while it is being copied. These parameters are set with three commands: glPixelTransfer, glPixelMap, and glPixelZoom. This reference page describes the effects on glCopyPixels of most, but not all, of the parameters specified by these three commands.
glCopyPixels copies values from each pixel with the lower left-hand corner at (x + $i$, y + $j$) for 0 <= $i$ < width and 0 <= $j$ < height. This pixel is said to be the $i$th pixel in the $j$th row. Pixels are copied in row order from the lowest to the highest row, left to right in each row.
type specifies whether color, depth, or stencil data is to be copied. The details of the transfer for each data type are as follows:
If the GL is in RGBA mode, the red, green, blue, and alpha components of each pixel that is read are converted to an internal floating-point with unspecified precision. The conversion maps the largest representable component value to 1.0, and component value 0 to 0.0. The resulting floating-point color values are then multiplied by GL_c_SCALE and added to GL_c_BIAS, where c is RED, GREEN, BLUE, and ALPHA for the respective color components. The results are clamped to the range [0,1]. 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.
If the GL_ARB_imaging extension is supported, the color values may be additionally processed by color-table lookups, color-matrix transformations, and convolution filters.
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 window coordinates ($x sub r ~+~ i , y sub r ~+~ j$), where ($x sub r , y sub r$) is the current raster position, and the pixel was the $i$th pixel in the $j$th row. 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 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 window coordinates ($x sub r ~+~ i , y sub r ~+~ j$), where ($x sub r , y sub r$) is the current raster position, and the pixel was the $i$th pixel in the $j$th row. 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 rasterization described thus far assumes pixel zoom
factors of 1.0. 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 $i$th location in
the $j$th row of the source 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_INVALID_VALUE is generated if either width or height is negative.
GL_INVALID_OPERATION is generated if type is GL_DEPTH and there is no depth buffer.
GL_INVALID_OPERATION is generated if type is GL_STENCIL and there is no stencil buffer.
GL_INVALID_OPERATION is generated if glCopyPixels is executed between the execution of glBegin and the corresponding execution of glEnd.