GLXCOPYCONTEXT(3G)

💅 GLXCOPYCONTEXT — the glXCopyContext page, section 3G of the GLX manual

okay bestie, sit down, hydrate, and let me tell you about glXCopyContext — the GL function that's literally just "copy that vibe from one context to another." it's giving clipboard energy but for rendering state. 💖

---

✨ C SPECIFICATION ✨

void glXCopyContext( Display *dpy,
                     GLXContext src,
                     GLXContext dst,
                     unsigned long mask )

delim $$

yes the delim $$ is really in there, it's troff doing troff things, we don't question it, we just respect it 🫶

---

🎀 PARAMETERS 🎀

• dpy — the connection to the X server. your little phone line to the X server, basically. 📞
• src — the source context. the one we're stealing the look from. 👑
• dst — the destination context. the one getting the glow-up. ✨
• mask — which portions of src's state are getting copied over to dst. you pick and choose, you're the curator here. 🎨

---

🌸 DESCRIPTION 🌸

So glXCopyContext copies selected groups of state variables from src to dst. and mask is the little menu where you circle what you want — it tells you exactly which groups of state variables are getting copied.

Here's the tea on mask: it contains the bitwise OR of the same symbolic names that you'd pass to the GL command glPushAttrib. and if you're feeling maximalist (valid), there's one single symbolic constant — GL_ALL_ATTRIB_BITS — that copies the maximum possible portion of rendering state. the whole wardrobe. the entire closet. 🔥

Now, the copy can only happen if the renderers named by src and dst share an address space. and when do two rendering contexts share an address space? two situations:

• both are nondirect and using the same server, OR
• both are direct and owned by a single process.

and lowkey the important bit: in the nondirect case, the calling threads don't need to share an address space — only their related rendering contexts do. so don't stress about the threads, stress about the contexts. 💀

Not all values for GL state can be copied, bestie. 😭 for example:

• pixel pack and unpack state — nope
• render mode state — nope
• select and feedback state — nope

and the state that can be copied is exactly the state that is manipulated by the GL command glPushAttrib. that's the whole rule, no cap.

oh and one more thing — an implicit glFlush is done by glXCopyContext if src is the current context for the calling thread. it just sneaks one in. 🧚

---

💜 NOTES 💜

let's define our terms because we're rigorous like that:

• A process is a single execution environment, implemented in a single address space, consisting of one or more threads.
• A thread is one of a set of subprocesses that share a single address space, but maintain separate program counters, stack spaces, and other related global data. and — plot twist — a thread that is the only member of its subprocess group is equivalent to a process. 🦋

---

💀 ERRORS 💀

here's where it gets dramatic. buckle up.

• BadMatch — generated if rendering contexts src and dst do not share an address space, or were not created with respect to the same screen. mismatched, incompatible, doomed. 💔
• BadAccess — generated if dst is current to any thread (including the calling thread!! yes, even you!!) at the time glXCopyContext is called.
• GLXBadCurrentWindow — generated if src is the current context and the current drawable is a window that is no longer valid. that window is gone, girl. 🙈
• GLXBadContext — generated if either src or dst is not a valid GLX context. one of them is a fake. 🚩

---

🌈 SEE ALSO 🌈

• glPushAttrib
• glXCreateContext
• glXIsDirect

---

and that's the whole page, periodt. 🎀 this was GLXCOPYCONTEXT from the GLX manual — the 3G section, printed up there in the corner and stamped down at the bottom, same name top and bottom because symmetry is iconic. go copy some context, bestie, and remember: shared address space or it didn't happen. 💖✨👑