GLINVALIDATEFRAMEBUF(3G)

πŸ’… GLINVALIDATEFRAMEBUF β€” the 3G manual page, but make it make sense

okay so bestie, welcome to glInvalidateFramebuffer(3G) β€” the manual page for glInvalidateFramebuffer and glInvalidateNamedFramebufferData, which are literally the "nah, throw that away" functions for your framebuffer attachments. no cap, it's giving "declutter your GPU" energy and i'm obsessed. πŸŽ€


✨ NAME ✨

glInvalidateFramebuffer, glInvalidateNamedFramebufferData β€” invalidate the content of some or all of a framebuffer's attachments πŸ—‘οΈβœ¨


🫢 C SPECIFICATION 🫢

void glInvalidateFramebuffer(GLenum target, GLsizei numAttachments,
                             const GLenum * attachments);

void glInvalidateNamedFramebufferData(GLuint framebuffer,
                                      GLsizei numAttachments,
                                      const GLenum *attachments);

like, copy that exactly pls, i'm not playing around with signatures 😭


🌸 PARAMETERS 🌸

  • target β€” tells glInvalidateFramebuffer which target the framebuffer object is attached to. the vibe check of "where do i even look".
  • framebuffer β€” the name of the framebuffer object, for glInvalidateNamedFramebufferData. it's the main character's ID, fr fr.
  • numAttachments β€” how many entries live in the attachments array. count them. don't lie.
  • attachments β€” a pointer to an array naming the attachments you want invalidated. the hit list πŸ’€

πŸ¦‹ DESCRIPTION πŸ¦‹

glInvalidateFramebuffer and glInvalidateNamedFramebufferData invalidate the entire contents of a specified set of attachments of a framebuffer. like, whole thing. not a little bit. the whole thing. periodt.

glInvalidateFramebuffer β€” the target-based one

for glInvalidateFramebuffer, the framebuffer object is the one bound to target. and target must be one of:

  • GL_FRAMEBUFFER
  • GL_READ_FRAMEBUFFER
  • GL_DRAW_FRAMEBUFFER

and heads up: GL_FRAMEBUFFER is equivalent to GL_DRAW_FRAMEBUFFER. yes bestie, they're the same thing, don't overthink it ✨

default framebuffers may also be invalidated if bound to target. iconic.

glInvalidateNamedFramebufferData β€” the name-based one

for glInvalidateNamedFramebufferData, framebuffer is the name of the framebuffer object. and if framebuffer is zero, the default draw framebuffer is affected. zero means default, iykyk.

🎯 which attachments are allowed?

the set of attachments whose contents are to be invalidated are specified in the attachments array, which contains numAttachments elements. so the array and the count gotta match, obviously.

if the specified framebuffer is a framebuffer object, each element of attachments must be one of:

  • GL_DEPTH_ATTACHMENT
  • GL_STENCIL_ATTACHMENT
  • GL_DEPTH_STENCIL_ATTACHMENT
  • GL_COLOR_ATTACHMENTi β€” where i is between zero and the value of GL_MAX_FRAMEBUFFER_ATTACHMENTS minus one

if the specified framebuffer is a default framebuffer, each element of attachments must be one of:

  • GL_FRONT_LEFT
  • GL_FRONT_RIGHT
  • GL_BACK_LEFT
  • GL_BACK_RIGHT
  • GL_AUXi
  • GL_ACCUM
  • GL_COLOR
  • GL_DEPTH
  • GL_STENCIL

and here's the little twist: GL_COLOR is treated as GL_BACK_LEFT for a double-buffered context and GL_FRONT_LEFT for a single-buffered context. the other attachments identify the corresponding specific buffer. slay, context-dependent behavior 🧚

πŸ’€ what actually happens

the entire contents of each specified attachment become undefined after execution of glInvalidateFramebuffer or glInvalidateNamedFramebufferData. undefined. not "reset", not "cleared", undefined. do not go reading them and expecting anything sensible, bestie πŸ™ˆ

if the framebuffer object is not complete, glInvalidateFramebuffer and glInvalidateNamedFramebufferData may be ignored. and no β€” this is not an error. it's just allowed to ghost you. πŸ«₯

πŸ”₯ ERRORS πŸ”₯

  • GL_INVALID_ENUM is generated by glInvalidateFramebuffer if target is not one of the accepted framebuffer targets.
  • GL_INVALID_OPERATION is generated by glInvalidateNamedFramebufferData if framebuffer is not zero or the name of an existing framebuffer object.
  • GL_INVALID_VALUE is generated if numAttachments is negative. (negative?? bestie. no.)
  • GL_INVALID_ENUM is generated if any element of attachments is not one of the accepted framebuffer attachment points, as described above.
  • GL_INVALID_OPERATION is generated if element of attachments is GL_COLOR_ATTACHMENTm where m is greater than or equal to the value of GL_MAX_COLOR_ATTACHMENTS.

πŸ‘‘ ASSOCIATED GETS πŸ‘‘

glGet() with argument GL_MAX_COLOR_ATTACHMENTS


🌈 VERSION SUPPORT 🌈

okay so the original had a whole big table and i can't do tables in here, so i'm giving it to you as a glow-up list instead β€” same facts, same energy, nothing dropped πŸ’–

available OpenGL versions checked: 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5.

  • glInvalidateFramebuffer β€” - for 2.0, - for 2.1, - for 3.0, - for 3.1, - for 3.2, - for 3.3, - for 4.0, - for 4.1, - for 4.2, βœ” for 4.3, βœ” for 4.4, βœ” for 4.5. so it showed up in 4.3 and never left. queen behavior πŸ‘‘
  • glInvalidateNamedFramebufferData β€” - for 2.0, - for 2.1, - for 3.0, - for 3.1, - for 3.2, - for 3.3, - for 4.0, - for 4.1, - for 4.2, - for 4.3, - for 4.4, βœ” for 4.5. only 4.5. late bloomer, but we respect it 🌸

⭐ SEE ALSO ⭐

  • glInvalidateTexSubImage()
  • glInvalidateTexImage()
  • glInvalidateBufferSubData()
  • glInvalidateBufferData()
  • glInvalidateSubFramebuffer()

the whole invalidate cinematic universe, honestly 🎬


Copyright Β© 2014 Khronos Group. This material may be distributed subject to the terms and conditions set forth in the Open Publication License, v 1.0, 8 June 1999. http://opencontent.org/openpub/.

Copyright Β© 2014 Khronos Group


aaaand that's the page, bestie 🫢 source was [FIXME: source], dated 08/09/2021, and it's the GLINVALIDATEFRAMEBUF(3G) manual β€” go forth and invalidate responsibly βœ¨πŸ’…

πŸ“¦ where this page comes from