GLDRAWPIXELS(3G)
β¨ NAME β¨
glDrawPixels β write a block of pixels to the frame buffer π
okay so this is the GLDRAWPIXELS(3G) page bestie, and it's a big one, so grab a snack π. It's split into parts, so buckle up and stay with me.
π C SPECIFICATION
void glDrawPixels( GLsizei width,
GLsizei height,
GLenum format,
GLenum type,
const GLvoid *pixels )
πΈ PARAMETERS
width,heightβ the dimensions of the pixel rectangle you're about to yeet into the frame buffer πformatβ specifies the format of the pixel data. The accepted symbolic constants areGL_COLOR_INDEX,GL_STENCIL_INDEX,GL_DEPTH_COMPONENT,GL_RGB,GL_BGR,GL_RGBA,GL_BGRA,GL_RED,GL_GREEN,GL_BLUE,GL_ALPHA,GL_LUMINANCE, andGL_LUMINANCE_ALPHA. So many options, we love choices β¨typeβ specifies the data type for pixels. The accepted symbolic constants areGL_UNSIGNED_BYTE,GL_BYTE,GL_BITMAP,GL_UNSIGNED_SHORT,GL_SHORT,GL_UNSIGNED_INT,GL_INT,GL_FLOAT,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, andGL_UNSIGNED_INT_2_10_10_10_REV. That's a whole alphabet of vibes fr fr πpixelsβ a pointer to the pixel data. just point at it bestie πβ¨
π DESCRIPTION π
So glDrawPixels reads pixel data straight out of memory and writes it into the frame buffer, positioned relative to the current raster position β provided that the raster position is valid. To set the current raster position, use glRasterPos. To find out if the raster position you set is actually valid, use glGet with the argument GL_CURRENT_RASTER_POSITION_VALID, and to query the raster position itself, use glGet with the argument GL_CURRENT_RASTER_POSITION. vibe check your raster position before you commit, bestie π«Ά
Several parameters define how the pixel data is encoded in memory, and they control how that pixel data gets processed before it lands in the frame buffer. These parameters get set with four commands: glPixelStore, glPixelTransfer, glPixelMap, and glPixelZoom. Heads up though β this reference page describes the effects on glDrawPixels of many, but not all, of the parameters specified by those four commands. iykyk π
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 those 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. And if type is GL_BITMAP, then plot twist: 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). periodt π
widthΓ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 gets advanced to the next four-byte boundary. That four-byte row alignment is specified by glPixelStore with the argument GL_UNPACK_ALIGNMENT, and you can set it 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 the details on these options. the way it has layers πβ¨
The widthΓheight pixels read from memory each get operated on in the same way, based on the values of several parameters specified by glPixelTransfer and glPixelMap. The details of those operations β plus the target buffer the pixels get drawn into β are specific to the format of the pixels, as specified by format. And format can assume one of 13 symbolic values:
π GL_COLOR_INDEX
Each pixel is a single value, a color index. It's converted to fixed-point with an unspecified number of bits to the right of the binary point, regardless of the memory data type. Floating-point values convert to true fixed-point values. Signed and unsigned integer data is converted with all fraction bits set to 0. Bitmap data converts to either 0 or 1.
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 goes to the right instead. 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 happens or not, the integer part of the index is then ANDed with 2^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
xn=xr+nmodwidth
yn=yr+βn/widthβ
where (xr,yr) 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. slay π¦
π GL_STENCIL_INDEX
Each pixel is a single value, a stencil index. It's converted to fixed-point with an unspecified number of bits to the right of the binary point, regardless of the memory data type. Floating-point values convert to true fixed-point values. Signed and unsigned integer data is converted with all fraction bits set to 0. Bitmap data converts to either 0 or 1.
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 goes 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 happens or not, the integer part of the index is then ANDed with 2^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
xn=xr+nmodwidth
yn=yr+βn/widthβ
where (xr,yr) is the current raster position. Only the pixel ownership test, the scissor test, and the stencil writemask affect these write operations. that's it, that's the whole list π
π GL_DEPTH_COMPONENT
Each pixel is a single-depth component. Floating-point data is converted directly to an internal floating-point value with unspecified precision. Signed integer data is mapped linearly to the internal floating-point value such that the most positive representable integer value maps to 1.0, and the most negative representable value maps to -1.0. Unsigned integer data is mapped similarly: the largest integer value maps to 1.0, and 0 maps to 0.0. The resulting floating-point depth value is then multiplied by GL_DEPTH_SCALE and added to GL_DEPTH_BIAS. The result is clamped to the range [0,1].
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
xn=xr+nmodwidth
yn=yr+βn/widthβ
where (xr,yr) 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. no cap β¨
π GL_RGBA
π GL_BGRA
Each pixel is a four-component group: for GL_RGBA, the red component comes first, followed by green, followed by blue, followed by alpha; for GL_BGRA the order is blue, green, red and then alpha. Floating-point values are converted directly to an internal floating-point value with unspecified precision. Signed integer values are mapped linearly to the internal floating-point value such that the most positive representable integer value maps to 1.0, and the most negative representable value maps to -1.0. (Note that this mapping does not convert 0 precisely to 0.0.) Unsigned integer data is mapped similarly: the largest integer value maps to 1.0, and 0 maps 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, every color component gets scaled by the size of the lookup table GL_PIXEL_MAP_c_TO_c, and then replaced by whatever value it references in that table. c is R, G, B, or A respectively. that's the whole trick bestie π
Then the GL takes those resulting RGBA colors and converts them to fragments by attaching the current raster position z coordinate and the texture coordinates to each pixel, and then handing out x and y window coordinates to the nth fragment so that:
xn=xr+nmodwidth
yn=yr+βn/widthβ
where (xr,yr) is the current raster position. Those pixel fragments then get treated exactly like the fragments you'd get from rasterizing points, lines, or polygons β texture mapping, fog, and all the fragment operations are applied before anything gets written to the frame buffer. no shortcuts, no skipping the queue π
GL_REDβ every pixel is a single red component. That component converts to the internal floating-point the same way the red component of an RGBA pixel does. Then it becomes an RGBA pixel with green and blue set to 0, and alpha set to 1. After that, it's treated as if it had been read as an RGBA pixel. glow-up complete β¨GL_GREENβ every pixel is a single green component. It converts to the internal floating-point the same way the green component of an RGBA pixel does. Then it becomes an RGBA pixel with red and blue set to 0, and alpha set to 1. After that, treated as if it had been read as an RGBA pixel. πGL_BLUEβ every pixel is a single blue component. Converts to the internal floating-point the same way the blue component of an RGBA pixel does. Then it becomes an RGBA pixel with red and green set to 0, and alpha set to 1. After that, treated as if it had been read as an RGBA pixel. πGL_ALPHAβ every pixel is a single alpha component. Converts to the internal floating-point the same way the alpha component of an RGBA pixel does. Then it becomes an RGBA pixel with red, green, and blue set to 0. After that, treated as if it had been read as an RGBA pixel. the invisible icon π»GL_RGBGL_BGRβ every pixel is a three-component group: red first, followed by green, followed by blue; forGL_BGR, the first component is blue, followed by green and then red. Each component converts to the internal floating-point the same way the red, green, and blue components of an RGBA pixel do. The color triple becomes an RGBA pixel with alpha set to 1. After that, treated as if it had been read as an RGBA pixel. πGL_LUMINANCEβ every pixel is a single luminance component. It converts to the internal floating-point the same way the red component of an RGBA pixel does. Then it becomes an RGBA pixel with red, green, and blue all set to the converted luminance value, and alpha set to 1. After that, treated as if it had been read as an RGBA pixel. βGL_LUMINANCE_ALPHAβ every pixel is a two-component group: luminance first, followed by alpha. Both components convert to the internal floating-point the same way the red component of an RGBA pixel does. Then they become an RGBA pixel with red, green, and blue set to the converted luminance value, and alpha set to the converted alpha value. After that, treated as if it had been read as an RGBA pixel. π¦
okay so here's the cheat sheet for what the valid type constants actually mean π
GL_UNSIGNED_BYTEβ unsigned 8-bit integerGL_BYTEβ signed 8-bit integerGL_BITMAPβ single bits in unsigned 8-bit integersGL_UNSIGNED_SHORTβ unsigned 16-bit integerGL_SHORTβ signed 16-bit integerGL_UNSIGNED_INTβ unsigned 32-bit integerGL_INTβ 32-bit integerGL_FLOATβ single-precision floating-pointGL_UNSIGNED_BYTE_3_3_2β unsigned 8-bit integerGL_UNSIGNED_BYTE_2_3_3_REVβ unsigned 8-bit integer with reversed component orderingGL_UNSIGNED_SHORT_5_6_5β unsigned 16-bit integerGL_UNSIGNED_SHORT_5_6_5_REVβ unsigned 16-bit integer with reversed component orderingGL_UNSIGNED_SHORT_4_4_4_4β unsigned 16-bit integerGL_UNSIGNED_SHORT_4_4_4_4_REVβ unsigned 16-bit integer with reversed component orderingGL_UNSIGNED_SHORT_5_5_5_1β unsigned 16-bit integerGL_UNSIGNED_SHORT_1_5_5_5_REVβ unsigned 16-bit integer with reversed component orderingGL_UNSIGNED_INT_8_8_8_8β unsigned 32-bit integerGL_UNSIGNED_INT_8_8_8_8_REVβ unsigned 32-bit integer with reversed component orderingGL_UNSIGNED_INT_10_10_10_2β unsigned 32-bit integerGL_UNSIGNED_INT_2_10_10_10_REVβ unsigned 32-bit integer with reversed component ordering
and now, the zoom plot twist: everything we just described assumes pixel zoom factors of 1. If glPixelZoom is used to change the x and y pixel zoom factors, pixels convert to fragments like this β if (xr, yr) is the current raster position, and a given pixel is in the nth column and mth row of the pixel rectangle, then fragments are generated for pixels whose centers are in the rectangle with corners at
(xr+zoomxn, yr+zoomym)
(xr+zoomx(n+1), yr+zoomy(m+1))
where zoomx is the value of GL_ZOOM_X and zoomy is the value of GL_ZOOM_Y. math girlies rise π§
β¨ NOTES β¨
GL_BGRandGL_BGRAare only valid for format if the GL version is 1.2 or greater.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, andGL_UNSIGNED_INT_2_10_10_10_REVare only valid for type if the GL version is 1.2 or greater.
read that twice bestie, version gates are not a vibe you wanna ignore π
π₯ ERRORS π₯
GL_INVALID_VALUEis generated if either width or height is negative. negative dimensions? absolutely notGL_INVALID_ENUMis generated if format or type is not one of the accepted values.GL_INVALID_OPERATIONis generated if format isGL_RED,GL_GREEN,GL_BLUE,GL_ALPHA,GL_RGB,GL_RGBA,GL_BGR,GL_BGRA,GL_LUMINANCE, orGL_LUMINANCE_ALPHA, and the GL is in color index mode.GL_INVALID_ENUMis generated if type isGL_BITMAPand format is not eitherGL_COLOR_INDEXorGL_STENCIL_INDEX.GL_INVALID_OPERATIONis generated if format isGL_STENCIL_INDEXand there is no stencil buffer.GL_INVALID_OPERATIONis generated ifglDrawPixelsis executed between the execution ofglBeginand the corresponding execution ofglEnd. like, do NOT do that. mid-begin is sacred ground πGL_INVALID_OPERATIONis generated if type is oneGL_UNSIGNED_BYTE_3_3_2,GL_UNSIGNED_BYTE_2_3_3_REV,GL_UNSIGNED_SHORT_5_6_5, ofGL_UNSIGNED_SHORT_5_6_5_REVand format is notGL_RGB.GL_INVALID_OPERATIONis generated if type is one ofGL_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, orGL_UNSIGNED_INT_2_10_10_10_REVand format is neitherGL_RGBAnorGL_BGRA.
π ASSOCIATED GETS π
glGetwith argumentGL_CURRENT_RASTER_POSITIONglGetwith argumentGL_CURRENT_RASTER_POSITION_VALID
π«Ά SEE ALSO π«Ά
glAlphaFunc(3G), glBlendFunc(3G), glCopyPixels(3G), glDepthFunc(3G), glLogicOp(3G), glPixelMap(3G), glPixelStore(3G), glPixelTransfer(3G), glPixelZoom(3G), glRasterPos(3G), glReadPixels(3G), glScissor(3G), glStencilFunc(3G)
and that's the whole page bestie β footer's sitting there reading GLDRAWPIXELS(3G), so you know exactly which manual you're holding. go forth and blit responsibly πβ¨
π¦ where this page comes from
- opensuse-leap 16.0: Mesa-libGL-devel 24.1.7-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- opensuse-leap 16.0: Mesa-libGL-devel 24.3.3-160000.3.1 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms