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β tellsglInvalidateFramebufferwhich target the framebuffer object is attached to. the vibe check of "where do i even look".framebufferβ the name of the framebuffer object, forglInvalidateNamedFramebufferData. it's the main character's ID, fr fr.numAttachmentsβ how many entries live in theattachmentsarray. 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_FRAMEBUFFERGL_READ_FRAMEBUFFERGL_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_ATTACHMENTGL_STENCIL_ATTACHMENTGL_DEPTH_STENCIL_ATTACHMENTGL_COLOR_ATTACHMENTiβ where i is between zero and the value ofGL_MAX_FRAMEBUFFER_ATTACHMENTSminus one
if the specified framebuffer is a default framebuffer, each element of attachments must be one of:
GL_FRONT_LEFTGL_FRONT_RIGHTGL_BACK_LEFTGL_BACK_RIGHTGL_AUXiGL_ACCUMGL_COLORGL_DEPTHGL_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,glInvalidateFramebufferandglInvalidateNamedFramebufferDatamay be ignored. and no β this is not an error. it's just allowed to ghost you. π«₯
π₯ ERRORS π₯
GL_INVALID_ENUMis generated byglInvalidateFramebufferiftargetis not one of the accepted framebuffer targets.GL_INVALID_OPERATIONis generated byglInvalidateNamedFramebufferDataifframebufferis not zero or the name of an existing framebuffer object.GL_INVALID_VALUEis generated ifnumAttachmentsis negative. (negative?? bestie. no.)GL_INVALID_ENUMis generated if any element ofattachmentsis not one of the accepted framebuffer attachment points, as described above.GL_INVALID_OPERATIONis generated if element ofattachmentsisGL_COLOR_ATTACHMENTmwhere m is greater than or equal to the value ofGL_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β-for2.0,-for2.1,-for3.0,-for3.1,-for3.2,-for3.3,-for4.0,-for4.1,-for4.2,βfor4.3,βfor4.4,βfor4.5. so it showed up in4.3and never left. queen behavior πglInvalidateNamedFramebufferDataβ-for2.0,-for2.1,-for3.0,-for3.1,-for3.2,-for3.3,-for4.0,-for4.1,-for4.2,-for4.3,-for4.4,βfor4.5. only4.5. late bloomer, but we respect it πΈ
β SEE ALSO β
glInvalidateTexSubImage()glInvalidateTexImage()glInvalidateBufferSubData()glInvalidateBufferData()glInvalidateSubFramebuffer()
the whole invalidate cinematic universe, honestly π¬
π COPYRIGHT π
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
- centos-stream 9: gl-manpages 1.1-24.20190306.el9 Β· MIT and Open Publication
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms