GLNEWLIST(3G)

πŸ“¦ version 1.1, in centos-stream 9, fedora 43, fedora 44

✨ GLNEWLIST ✨

okay bestie, we're in the 3G corner of the manual (that's the OpenGL one, iykyk) and today's main characters are glNewList and glEndList β€” the duo that literally builds your display lists. slay.


πŸŽ€ NAME πŸŽ€

glNewList, glEndList β€” create or replace a display list. that's it, that's the job. πŸ’…


πŸ’… C SPECIFICATION πŸ’…

void glNewList( GLuint list,
                GLenum mode )

🌸 PARAMETERS 🌸

  • list β€” specifies the display-list name. yes, it's literally just the name, girl.
  • mode β€” specifies the compilation mode, which can be GL_COMPILE or GL_COMPILE_AND_EXECUTE.

πŸ’… C SPECIFICATION (round two, the sequel) πŸ’…

void glEndList( void )

no arguments. no drama. just vibes. πŸ¦‹


πŸ‘‘ DESCRIPTION πŸ‘‘

so picture this: display lists are groups of GL commands that have been stored for subsequent execution. they're created with glNewList. and then β€” this is the important part β€” all subsequent commands get placed into the display list, in the order issued, until glEndList is called. periodt. πŸ’–

glNewList has two arguments:

  • the first argument, list, is a positive integer that becomes the unique name for the display list. names can be created and reserved with glGenLists and tested for uniqueness with glIsList. no cap.
  • the second argument, mode, is a symbolic constant that can assume one of two values:
    • GL_COMPILE β€” commands are merely compiled. they just sit there, being stored. iconic.
    • GL_COMPILE_AND_EXECUTE β€” commands are executed as they are compiled into the display list. multitasking queen behavior.

okay but here's the ✨ twist ✨. certain commands are not compiled into the display list at all β€” they're executed immediately, regardless of the display-list mode. the way that these just refuse to be contained... 😭

  • glAreTexturesResident
  • glColorPointer
  • glDeleteLists
  • glDeleteTextures
  • glDisableClientState
  • glEdgeFlagPointer
  • glEnableClientState
  • glFeedbackBuffer
  • glFinish
  • glFlush
  • glGenLists
  • glGenTextures
  • glIndexPointer
  • glInterleavedArrays
  • glIsEnabled
  • glIsList
  • glIsTexture
  • glNormalPointer
  • glPopClientAttrib
  • glPixelStore
  • glPushClientAttrib
  • glReadPixels
  • glRenderMode
  • glSelectBuffer
  • glTexCoordPointer
  • glVertexPointer

...and all of the glGet commands. all of them. every last one. πŸ’€


similarly, glTexImage1D, glTexImage2D, and glTexImage3D are executed immediately and not compiled into the display list when their first argument is GL_PROXY_TEXTURE_1D, GL_PROXY_TEXTURE_1D, or GL_PROXY_TEXTURE_3D, respectively.

(and yes bestie, the manpage really does say GL_PROXY_TEXTURE_1D twice there. i'm not fixing it, i'm not touching it, i'm just reporting the facts. 🫢)


when the GL_ARB_imaging extension is supported, glHistogram executes immediately when its argument is GL_PROXY_HISTOGRAM. similarly, glColorTable executes immediately when its first argument is glPROXY_COLOR_TABLE, glPROXY_POST_CONVOLUTION_COLOR_TABLE, or glPROXY_POST_COLOR_MATRIX_COLOR_TABLE.

when the GL_ARB_multitexture extension is supported, glClientActiveTextureARB is not compiled into display lists, but executed immediately. it's giving independent. it's giving can't be tamed. 🧚


and then, when glEndList is encountered, the display-list definition is completed by associating the list with the unique name list (specified in the glNewList command). and listen β€” if a display list with name list already exists, it is replaced only when glEndList is called. not before. not mid-way. only at glEndList. the commitment!!! πŸ’œ


🌈 NOTES 🌈

glCallList and glCallLists can be entered into display lists. but here's the tea: commands in the display list or lists executed by glCallList or glCallLists are not included in the display list being created β€” even if the list creation mode is GL_COMPILE_AND_EXECUTE. they're doing their own thing, separately. main character energy only.

a display list is just a group of commands and arguments, so errors generated by commands in a display list must be generated when the list is executed. if the list is created in GL_COMPILE mode, errors are not generated until the list is executed. so like... the error is just ✨ pending ✨ until execution time. no cap.


πŸ’€ ERRORS πŸ’€

  • GL_INVALID_VALUE is generated if list is 0. zero is not the moment, bestie.
  • GL_INVALID_ENUM is generated if mode is not an accepted value.
  • GL_INVALID_OPERATION is generated if glEndList is called without a preceding glNewList, or if glNewList is called while a display list is being defined. you can't start a new list while you're still in the middle of one. one at a time, girl.
  • GL_INVALID_OPERATION is generated if glNewList or glEndList is executed between the execution of glBegin and the corresponding execution of glEnd.
  • GL_OUT_OF_MEMORY is generated if there is insufficient memory to compile the display list. and here's the important bit: if the GL version is 1.1 or greater, no change is made to the previous contents of the display list, if any, and no other change is made to the GL state. (it is as if no attempt had been made to create the new display list.) literally like nothing happened. the audacity. 😭

πŸ”₯ ASSOCIATED GETS πŸ”₯

  • glIsList
  • glGet with argument GL_LIST_INDEX
  • glGet with argument GL_LIST_MODE

πŸ¦‹ SEE ALSO πŸ¦‹

  • glCallList(3G)
  • glCallLists(3G)
  • glDeleteLists(3G)
  • glGenLists(3G)

okay that's the whole page bestie, you're officially a display list expert now, go forth and compile responsibly πŸ’–βœ¨πŸŽ€

this little love letter came straight out of the GLNEWLIST(3G) manual page, section 3G, and yeah β€” the header and the footer both just say GLNEWLIST(3G) back at you, so that's the version energy we're working with. mwah. πŸ’…πŸŒΈ

πŸ“¦ where this page comes from