1Name 2 3 NV_pack_subimage 4 5Name Strings 6 7 GL_NV_pack_subimage 8 9Contact 10 11 Peter Pipkorn, NVIDIA Corporation (ppipkorn 'at' nvidia.com) 12 13Contributors 14 15 Pat Brown, NVIDIA 16 Nicolai de Haan, NVIDIA 17 Greg Roth, NVIDIA 18 19Status 20 21 Complete. 22 23Version 24 25 Last Modifed Date: Oct 07, 2012 26 Author Revision: 3 27 28Number 29 30 OpenGL ES Extension #132 31 32Dependencies 33 34 OpenGLES 2.0 is required. 35 36 The extension is written against the OpenGL ES 2.0.25 specification. 37 38 EXT_unpack_subimage is required. 39 40Overview 41 42 This OpenGL ES 2.0 extension adds support for GL_PACK_ROW_LENGTH_NV, 43 GL_PACK_SKIP_ROWS_NV and GL_PACK_SKIP_PIXELS_NV as valid enums to 44 PixelStore. The functionality is the same as in OpenGL. These are 45 useful to update a sub-rectangle in host memory with data that can 46 be read from the framebuffer or a texture (using FBO and texture 47 attachments). 48 49New Procedures and Functions 50 51 None 52 53New Tokens 54 55 Accepted by the <pname> parameters of PixelStorei, 56 GetIntegerv, and GetFloatv: 57 58 GL_PACK_ROW_LENGTH_NV 0x0D02 59 GL_PACK_SKIP_ROWS_NV 0x0D03 60 GL_PACK_SKIP_PIXELS_NV 0x0D04 61 62Additions to the OpenGL ES 2.0 Specification 63 64 Modifications to Table 3.4 (PixelStore parameters for ReadPixels) 65 66 Add the following entries: 67 68 Parameter Name Type Initial Value Valid Range 69 ============== ==== ============= =========== 70 PACK_ROW_LENGTH_NV integer 0 [0,Infinity) 71 PACK_SKIP_ROWS_NV integer 0 [0,Infinity) 72 PACK_SKIP_PIXELS_NV integer 0 [0,Infinity) 73 74 75 Note: The description of the behavior of the added PACK* PixelStore 76 parameters is covered by the following existing text from 4.3.1 77 subsection "Placement in Client Memory": 78 79 Groups of elements are placed in memory just as they are taken 80 from memory for TexImage2D. That is, the ith group of the jth 81 row (corresponding to the ith pixel in the jth row) is placed in 82 memory just where the ith group of the jth row would be taken 83 from for TexImage2D. See Unpacking under section 3.6.2. The only 84 difference is that the storage mode parameters whose names begin 85 with PACK_ are used instead of those whose names begin with 86 UNPACK_. 87 88 The equivalent UNPACK_ storage mode parametes are documented by the 89 text added by EXT_unpack_subimage. As such, no additional 90 documentation language is required here. 91 92Errors 93 94 None 95 96New State 97 98 Modifications to Table 6.12 Pixels in section 6.2 State Tables: 99 100 Get Value Type Get Cmnd Initial Description Sec. Attribute 101 Value 102 ==================== ==== =========== ======= ============================ ===== =========== 103 PACK_ROW_LENGTH_NV Z+ GetIntegerv 0 Value of PACK_ROW_LENGTH_NV 4.3.1 pixel-store 104 PACK_SKIP_ROWS_NV Z+ GetIntegerv 0 Value of PACK_SKIP_ROWS_NV 4.3.1 pixel-store 105 PACK_SKIP_PIXELS_NV Z+ GetIntegerv 0 Value of PACK_SKIP_PIXELS_NV 4.3.1 pixel-store 106 107 108Issues 109 110 1. Can't this be done with repeated calls to ReadPixels? 111 112 RESOLVED: Yes, it is possible to pack pixels into a sub- 113 rectangle in host memory by by calling this function for one 114 line at a time with <height> of 1 advancing the <data> pointer 115 each time, but this could add unnecessary burden on the CPU 116 system. Specifying GL_PACK_ROW_LENGTH_NV makes it possible to 117 pack sub-rectangles of pixels with lower overhead. 118 119 2. Should the corresponding UNPACK enums be added? 120 121 RESOLVED: No, it should be done in a separate extension. There 122 is no functional dependency between the PACK enums and the 123 UNPACK enums. However, there is a language dependency. This 124 extension extends the language added by EXT_unpack_subimage. 125 Since this is intended to ship on platforms that support both, 126 Nothing is lost by adding a dependency for this reason. 127 128 3. Are these PACK_SKIP_* tokens strictly necessary? 129 130 RESOLVED: No. The same functionality can be achieved by 131 advancing the pixel pointer to host memory appropriately before 132 issuing an packing function call. They are included here for 133 both completeness and for convenience. 134 135 4. Should PACK_SKIP_IMAGES and PACK_IMAGE_HEIGHT be included? 136 137 RESOLVED: No. Without support for GetTexImage, their inclusion 138 makes less sense. The UNPACK_* equivalents were also left out 139 of EXT_unpack_subimage, which makes adding them here more 140 complicated to do right. 141 142Revision History 143 Rev. Date Author Changes 144 ---- ------------ --------- ------------------------------------- 145 3 07 Nov 2012 groth Added issue clarifications and a note 146 about existing spec language. 147 2 23 Oct 2012 groth Removed references to 3D texture images. 148 1 02 Oct 2009 ppipkorn Original draft. 149 150