{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":39809720,"defaultBranch":"main","name":"virtualgl","ownerLogin":"VirtualGL","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2015-07-28T02:51:32.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/13406472?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1709143440.0","currentOid":""},"activityList":{"items":[{"before":"bdc9fc2dad567d51f97d25ac95564a52f921dfe4","after":"024ee666a5b1542e2f54e1ae9559dea58a3f7e26","ref":"refs/heads/main","pushedAt":"2024-07-19T16:46:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"EGLBE: Always expose GLX_EXT_framebuffer_sRGB\n\n... regardless of which EGL API version the underlying EGL\nimplementation supports.  Referring to\n9882331e59c3a8c44defff9c621e971833ca2126, sRGB rendering is required by\nthe OpenGL 3.0 spec.  We can't support GLX_ARB_create_context* with EGL\n1.4- because eglCreateContext() lacks the necessary attributes, but\nnothing prevents us from supporting GLX_EXT_framebuffer_sRGB with any\nEGL API version.  (Making that extension contingent upon EGL 1.5 was an\nerror on my part when I authored\n9882331e59c3a8c44defff9c621e971833ca2126.)  This is known to affect\nVMware Linux guests.\n\nThis commit also modifies GLXspheres so that it only checks for the\nexistence of GLX_EXT_framebuffer_sRGB if -srgb is specified.","shortMessageHtmlLink":"EGLBE: Always expose GLX_EXT_framebuffer_sRGB"}},{"before":"50b07e0f16dbcf02b89bc488852af59e9d139a98","after":"88d071c5dc5c861119c95562ce616d39496a840a","ref":"refs/heads/3.0.x","pushedAt":"2024-07-19T16:46:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"EGLBE: Always expose GLX_EXT_framebuffer_sRGB\n\n... regardless of which EGL API version the underlying EGL\nimplementation supports.  Referring to\n9882331e59c3a8c44defff9c621e971833ca2126, sRGB rendering is required by\nthe OpenGL 3.0 spec.  We can't support GLX_ARB_create_context* with EGL\n1.4- because eglCreateContext() lacks the necessary attributes, but\nnothing prevents us from supporting GLX_EXT_framebuffer_sRGB with any\nEGL API version.  (Making that extension contingent upon EGL 1.5 was an\nerror on my part when I authored\n9882331e59c3a8c44defff9c621e971833ca2126.)  This is known to affect\nVMware Linux guests.\n\nThis commit also modifies GLXspheres so that it only checks for the\nexistence of GLX_EXT_framebuffer_sRGB if -srgb is specified.","shortMessageHtmlLink":"EGLBE: Always expose GLX_EXT_framebuffer_sRGB"}},{"before":"80e62ed6d6598d538199a45204b09148fde33a00","after":"50b07e0f16dbcf02b89bc488852af59e9d139a98","ref":"refs/heads/3.0.x","pushedAt":"2024-07-11T17:02:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"vglrun: Add --version switch\n\nCloses #257","shortMessageHtmlLink":"vglrun: Add --version switch"}},{"before":"75526d3cfe4d1562a1d299408c3ff6ca55c4d218","after":"bdc9fc2dad567d51f97d25ac95564a52f921dfe4","ref":"refs/heads/main","pushedAt":"2024-07-11T17:02:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"vglrun: Add --version switch\n\nCloses #257","shortMessageHtmlLink":"vglrun: Add --version switch"}},{"before":"31d3e88f426fdcf457eb60b3d0640db783c45a35","after":"75526d3cfe4d1562a1d299408c3ff6ca55c4d218","ref":"refs/heads/main","pushedAt":"2024-07-11T16:36:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Doc: Clarify security risks of GLX + EGL back ends\n\n(+ parentheses police)","shortMessageHtmlLink":"Doc: Clarify security risks of GLX + EGL back ends"}},{"before":"f10a08efde0ace7cb701577a4ca334598b47b8c3","after":"80e62ed6d6598d538199a45204b09148fde33a00","ref":"refs/heads/3.0.x","pushedAt":"2024-07-11T16:36:52.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Doc: Clarify security risks of GLX + EGL back ends\n\n(+ parentheses police)","shortMessageHtmlLink":"Doc: Clarify security risks of GLX + EGL back ends"}},{"before":"a51eacf49fa5bd017ce0e312b923ae877b2271fd","after":"31d3e88f426fdcf457eb60b3d0640db783c45a35","ref":"refs/heads/main","pushedAt":"2024-06-28T22:40:28.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"eglxfakerut: Fix build with recent Mesa releases\n\nAt some point prior to v23.1.4, Mesa stopped exposing\neglCreatePlatformPixmapSurfaceEXT() in the EGL link library, but the\nfunction can still be accessed through eglGetProcAddress() (as is the\ncase with eglCreatePlatformWindowSurfaceEXT().)","shortMessageHtmlLink":"eglxfakerut: Fix build with recent Mesa releases"}},{"before":"c47b07ef6d8d37ef2ec06e21102beb831fdebcd4","after":"a51eacf49fa5bd017ce0e312b923ae877b2271fd","ref":"refs/heads/main","pushedAt":"2024-03-07T20:56:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Doc: Remove VMware Workstation chapter\n\nReferring to #248, VMware Workstation v16.2.x+ now defaults to using a\nVulkan renderer to access the GPU, which makes VirtualGL worthless, and\nVMware's \"legacy\" OpenGL renderer doesn't work with VirtualGL anymore\n(for unknown reasons.)","shortMessageHtmlLink":"Doc: Remove VMware Workstation chapter"}},{"before":"94ceaa20c1daac5873c78ec1dfce05dafdf83282","after":"c47b07ef6d8d37ef2ec06e21102beb831fdebcd4","ref":"refs/heads/main","pushedAt":"2024-03-01T18:42:06.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"EGLX: Don't allow eglBindTexImage() w/ window surf\n\nThe EGL spec says that eglBindTexImage() is only for Pbuffer surfaces\nthat support EGL_BIND_TO_TEXTURE_RGB or EGL_BIND_TO_TEXTURE_RGBA.\nPiglit seems to think that the function should work with Pixmap surfaces\nas well, but that's irrelevant since we don't support Pixmap surfaces.","shortMessageHtmlLink":"EGLX: Don't allow eglBindTexImage() w/ window surf"}},{"before":"e025f9308b3a56cd1e52e0e2b08b531528277b1d","after":"94ceaa20c1daac5873c78ec1dfce05dafdf83282","ref":"refs/heads/main","pushedAt":"2024-02-28T18:09:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"CI: Use libjpeg-turbo 3.0.2","shortMessageHtmlLink":"CI: Use libjpeg-turbo 3.0.2"}},{"before":"2c98496d33ec24de36ffe6432a6c4bc89d96aa80","after":"e025f9308b3a56cd1e52e0e2b08b531528277b1d","ref":"refs/heads/main","pushedAt":"2024-02-28T02:47:13.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"GLXSpheres: Fix segfault w/ -srgb\n\nWe can't check for the existence of GLX_EXT_framebuffer_sRGB until the\nX display has been opened.  Oops.","shortMessageHtmlLink":"GLXSpheres: Fix segfault w/ -srgb"}},{"before":"5217ce28c4fe5beca33d9df8aab9c87ca2881e95","after":"f10a08efde0ace7cb701577a4ca334598b47b8c3","ref":"refs/heads/3.0.x","pushedAt":"2024-02-28T02:47:13.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"GLXSpheres: Fix segfault w/ -srgb\n\nWe can't check for the existence of GLX_EXT_framebuffer_sRGB until the\nX display has been opened.  Oops.","shortMessageHtmlLink":"GLXSpheres: Fix segfault w/ -srgb"}},{"before":"83875f8093f2581a7b121a667a68794b6f46b5dc","after":"2c98496d33ec24de36ffe6432a6c4bc89d96aa80","ref":"refs/heads/main","pushedAt":"2024-02-26T22:19:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"dlfaker: Interpose \"libEGL.so\", not \"*/libEGL.so\"\n\nReferring to 211f71937d4f88363eef3e459f4f60479ba0d26c, it turns out that\nFirefox is an example of a 3D application that calls\ndlopen(\"libEGL.so\", ...).  (This is why we can't have nice things.)\nHowever, when ANGLE opens its EGL interposer, it always does so using a\nfull pathname.  Thus, it is (hopefully!) safe to assume that VirtualGL's\ndlopen() interposer should interpose calls to dlopen(\"libEGL.so\", ...)\nbut not calls to dlopen(\"*/libEGL.so\", ...).","shortMessageHtmlLink":"dlfaker: Interpose \"libEGL.so\", not \"*/libEGL.so\""}},{"before":"5a91ca0723448355ef1019edc0165226b2e53dc3","after":"83875f8093f2581a7b121a667a68794b6f46b5dc","ref":"refs/heads/main","pushedAt":"2024-02-26T18:49:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Doc: Update Chrome app recipe (again)\n\n--use-gl=egl actually still works.  You just have to pass\n--in-process-gpu to Chrome rather than --disable-seccomp-filter-sandbox.\n\nAccording to Google, --use-gl=egl is on its way out, because Chrome\nrelies on ANGLE for more than just WebGL these days.  However,\n--in-process-gpu will hopefully buy us some time until the issues with\nChrome/ANGLE (namely its janky visual selection method and the\nperformance issues with ANGLE's desktop OpenGL back ends) are resolved.","shortMessageHtmlLink":"Doc: Update Chrome app recipe (again)"}},{"before":"211f71937d4f88363eef3e459f4f60479ba0d26c","after":"5a91ca0723448355ef1019edc0165226b2e53dc3","ref":"refs/heads/main","pushedAt":"2024-02-24T21:46:37.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"EGLX: Optional hacks to support Chrome/ANGLE\n\nChrome/ANGLE attempts to reproduce the visual matching algorithm from\nGTK v3.15.2 through 4.3.1 (refer to\n398e941653137443a662bc726d82a04012eb5ea1), but it does so by sending raw\nGLX requests to and receiving raw GLX replies from the X server.  Thus,\nthere is nothing for VirtualGL to interpose, and Chrome picks \"system\"\nand \"RGBA\" visuals based solely on OpenGL rendering attributes assigned\nto the 2D X server visuals by the 2D X server's GLX implementation, not\non OpenGL rendering attributes assigned to the visuals by VirtualGL.  As\na result, the RGBA visual that Chrome picks is not associated with any\nEGLConfig that VirtualGL returns.  To work around this, two hacks can\nnow be enabled by setting an undocumented environment variable\n(VGL_CHROMEHACK) to 1:\n\n- glxvisual::buildVisAttribTable() scores the 2D X server visuals in the\n  same way that Chrome does, preferring an alpha-enabled visual without\n  a depth buffer, a stencil buffer, or multisampling.\n- The EGL/X11 interposer chooses the highest-scoring visual and assigns\n  its visual ID to the value of the EGL_NATIVE_VISUAL_ID attribute for\n  any EGLConfigs that have an 8-bit alpha channel.\n\nVGL_CHROMEHACK automatically enables VGL_PROBEGLX.\n\nThis should allow VirtualGL to work with Chrome v112+ if Chrome is\npassed '--disable-seccomp-filter-sandbox --use-angle=gl-egl'.\n\nRefer to #229","shortMessageHtmlLink":"EGLX: Optional hacks to support Chrome/ANGLE"}},{"before":"e706064088d1baf7c370ae5b36bbd1af60675db8","after":"211f71937d4f88363eef3e459f4f60479ba0d26c","ref":"refs/heads/main","pushedAt":"2024-02-24T15:02:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"dlfaker: Don't interpose dlopen(\"libEGL.so\", ...)\n\nANGLE (Almost Native Graphics Layer Engine) is an OpenGL ES emulator\nthat provides its own EGL interposer and translates EGL + OpenGL ES\nfunction calls from 3D applications into EGL + OpenGL, EGL + OpenGL ES,\nGLX + OpenGL, GLX + OpenGL ES, or Vulkan function calls.  ANGLE's EGL\ninterposer is named libEGL.so, so VirtualGL's dlopen() interposer\nintercepted dlopen() calls that ANGLE makes to open its EGL interposer,\nand that caused VirtualGL to interpose between the 3D application and\nANGLE.  This is incorrect for multiple reasons, not the least of which\nis that ANGLE's EGL interposer implements certain ANGLE-specific EGL\nextensions.  VirtualGL should instead interpose between ANGLE's back end\nand the X server.  Fortunately, because ANGLE's back end calls\ndlopen(\"libEGL.so.1\", ...) to load the real EGL library, we can move\nVirtualGL from in front of ANGLE to behind ANGLE by simply changing the\nmatching criteria in VirtualGL's dlopen() interposer. Since libEGL.so is\nnormally part of the (optional) EGL SDK, not the EGL run-time, non-ANGLE\n3D applications should not be calling dlopen(\"libEGL.so\", ...).  Thus,\nthis change is hopefully innocuous.","shortMessageHtmlLink":"dlfaker: Don't interpose dlopen(\"libEGL.so\", ...)"}},{"before":"182c9edbf636a909350073e49c6f1fbc3a50453b","after":"e706064088d1baf7c370ae5b36bbd1af60675db8","ref":"refs/heads/main","pushedAt":"2024-02-21T03:22:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Doc: Add Unity application recipe\n\n(same story as Chrome v85-111)\n\nAlso change \"OpenGL ES\" to \"ANGLE\" in the Chrome/Chromium app recipe.\n(ANGLE is an OpenGL ES emulator.)\n\nCloses #191","shortMessageHtmlLink":"Doc: Add Unity application recipe"}},{"before":"37dd3997e5ddcf046dd8c36c70a2ea8f38846ca2","after":"5217ce28c4fe5beca33d9df8aab9c87ca2881e95","ref":"refs/heads/3.0.x","pushedAt":"2024-02-21T02:16:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Faker: Don't clear new Pbuffer if drawing to FBO\n\nSince the beginning, VirtualGL has cleared new \"virtual window\" Pbuffers\n(Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers\nare made current for the first time.  Unlike new X windows, the contents\nof new Pbuffers are undefined, and \"back in the day\", some OpenGL\nimplementations did not clear new Pbuffers.  Applications were\nparticularly economical with their 3D rendering back then, and some of\nthem relied on the fact that new X windows start out blank.  Thus,\nVirtualGL had to clear new virtual window Pbuffers, particularly ones\nthat it created in midstream (in response to a window resize that\noccurred between glXSwapBuffers() or glXMakeCurrent() calls.)  Since the\nPbuffer clearing code was introduced before VirtualGL was open sourced,\ninformation about the specific OpenGL implementations and 3D\napplications that necessitated it has been lost to history.  Clearing\nnew virtual window Pbuffers is likely never necessary in 2024, and it\ndefinitely isn't necessary unless the default framebuffer is bound to\nthe GL_DRAW_FRAMEBUFFER target.  (FBOs weren't a thing \"back in the\nday.\")\n\nVirtualGL handles midstream window resizes in the body of glViewport(),\nbut because FBOs and their bindings are attached to a specific context\nrather than a specific drawable, the first glViewport() call that a 3D\napplication makes after its window is resized might be made while an FBO\nis bound to the GL_DRAW_FRAMEBUFFER target.  That is the case with\nFirefox, so VirtualGL's attempt to clear the new virtual window Pbuffer\nthat it created in the body of glViewport() cleared part of an FBO\ninstead, resulting in the disappearance of random characters or other\nelements of the Firefox window.\n\nModern OpenGL implementations seem to clear new Pbuffers, at least in my\nlimited testing, so we could probably get away with jettisoning the\nPbuffer clearing code altogether.  However, the minimally invasive fix\nis simply to forego clearing a new virtual window Pbuffer if an FBO is\nbound to the GL_DRAW_FRAMEBUFFER target.\n\nNote that this appears to have been the \"update issue\" that I observed\nin certain versions of Firefox and documented in\nhttps://github.com/VirtualGL/virtualgl/issues/228#issuecomment-1458759288\nIn fact, the issue was always reproducible with either back end.  I\ndidn't always observe it because it didn't always occur unless you\nresized the Firefox window repeatedly, and it was more likely to occur\nwith the GLX back end than with the EGL back end.","shortMessageHtmlLink":"Faker: Don't clear new Pbuffer if drawing to FBO"}},{"before":"26d713ec2a542128caa85a446d81794536169e90","after":"ac29587d377fc8eaf21f8012ed23b798365c39ce","ref":"refs/heads/2.6.x","pushedAt":"2024-02-21T02:16:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Faker: Don't clear new Pbuffer if drawing to FBO\n\nSince the beginning, VirtualGL has cleared new \"virtual window\" Pbuffers\n(Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers\nare made current for the first time.  Unlike new X windows, the contents\nof new Pbuffers are undefined, and \"back in the day\", some OpenGL\nimplementations did not clear new Pbuffers.  Applications were\nparticularly economical with their 3D rendering back then, and some of\nthem relied on the fact that new X windows start out blank.  Thus,\nVirtualGL had to clear new virtual window Pbuffers, particularly ones\nthat it created in midstream (in response to a window resize that\noccurred between glXSwapBuffers() or glXMakeCurrent() calls.)  Since the\nPbuffer clearing code was introduced before VirtualGL was open sourced,\ninformation about the specific OpenGL implementations and 3D\napplications that necessitated it has been lost to history.  Clearing\nnew virtual window Pbuffers is likely never necessary in 2024, and it\ndefinitely isn't necessary unless the default framebuffer is bound to\nthe GL_DRAW_FRAMEBUFFER target.  (FBOs weren't a thing \"back in the\nday.\")\n\nVirtualGL handles midstream window resizes in the body of glViewport(),\nbut because FBOs and their bindings are attached to a specific context\nrather than a specific drawable, the first glViewport() call that a 3D\napplication makes after its window is resized might be made while an FBO\nis bound to the GL_DRAW_FRAMEBUFFER target.  That is the case with\nFirefox, so VirtualGL's attempt to clear the new virtual window Pbuffer\nthat it created in the body of glViewport() cleared part of an FBO\ninstead, resulting in the disappearance of random characters or other\nelements of the Firefox window.\n\nModern OpenGL implementations seem to clear new Pbuffers, at least in my\nlimited testing, so we could probably get away with jettisoning the\nPbuffer clearing code altogether.  However, the minimally invasive fix\nis simply to forego clearing a new virtual window Pbuffer if an FBO is\nbound to the GL_DRAW_FRAMEBUFFER target.\n\nNote that this appears to have been the \"update issue\" that I observed\nin certain versions of Firefox and documented in\nhttps://github.com/VirtualGL/virtualgl/issues/228#issuecomment-1458759288\nIn fact, the issue was always reproducible with either back end.  I\ndidn't always observe it because it didn't always occur unless you\nresized the Firefox window repeatedly, and it was more likely to occur\nwith the GLX back end than with the EGL back end.","shortMessageHtmlLink":"Faker: Don't clear new Pbuffer if drawing to FBO"}},{"before":"d950b031bc66bca3a47d569c385d9d1b89d4140d","after":"182c9edbf636a909350073e49c6f1fbc3a50453b","ref":"refs/heads/main","pushedAt":"2024-02-21T02:14:17.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Faker: Don't clear new Pbuffer if drawing to FBO\n\nSince the beginning, VirtualGL has cleared new \"virtual window\" Pbuffers\n(Pbuffers that it creates to emulate OpenGL windows) when the Pbuffers\nare made current for the first time.  Unlike new X windows, the contents\nof new Pbuffers are undefined, and \"back in the day\", some OpenGL\nimplementations did not clear new Pbuffers.  Applications were\nparticularly economical with their 3D rendering back then, and some of\nthem relied on the fact that new X windows start out blank.  Thus,\nVirtualGL had to clear new virtual window Pbuffers, particularly ones\nthat it created in midstream (in response to a window resize that\noccurred between glXSwapBuffers() or glXMakeCurrent() calls.)  Since the\nPbuffer clearing code was introduced before VirtualGL was open sourced,\ninformation about the specific OpenGL implementations and 3D\napplications that necessitated it has been lost to history.  Clearing\nnew virtual window Pbuffers is likely never necessary in 2024, and it\ndefinitely isn't necessary unless the default framebuffer is bound to\nthe GL_DRAW_FRAMEBUFFER target.  (FBOs weren't a thing \"back in the\nday.\")\n\nVirtualGL handles midstream window resizes in the body of glViewport(),\nbut because FBOs and their bindings are attached to a specific context\nrather than a specific drawable, the first glViewport() call that a 3D\napplication makes after its window is resized might be made while an FBO\nis bound to the GL_DRAW_FRAMEBUFFER target.  That is the case with\nFirefox, so VirtualGL's attempt to clear the new virtual window Pbuffer\nthat it created in the body of glViewport() cleared part of an FBO\ninstead, resulting in the disappearance of random characters or other\nelements of the Firefox window.\n\nModern OpenGL implementations seem to clear new Pbuffers, at least in my\nlimited testing, so we could probably get away with jettisoning the\nPbuffer clearing code altogether.  However, the minimally invasive fix\nis simply to forego clearing a new virtual window Pbuffer if an FBO is\nbound to the GL_DRAW_FRAMEBUFFER target.\n\nNote that this appears to have been the \"update issue\" that I observed\nin certain versions of Firefox and documented in\nhttps://github.com/VirtualGL/virtualgl/issues/228#issuecomment-1458759288\nIn fact, the issue was always reproducible with either back end.  I\ndidn't always observe it because it didn't always occur unless you\nresized the Firefox window repeatedly, and it was more likely to occur\nwith the GLX back end than with the EGL back end.","shortMessageHtmlLink":"Faker: Don't clear new Pbuffer if drawing to FBO"}},{"before":"80a2b142bd0210960926da87de7460a77298df73","after":"d950b031bc66bca3a47d569c385d9d1b89d4140d","ref":"refs/heads/main","pushedAt":"2024-02-20T18:12:13.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"servertest: Allow setting eglxfakerut thread count\n\nSome drivers need this.","shortMessageHtmlLink":"servertest: Allow setting eglxfakerut thread count"}},{"before":"f1aab09360bc061c876a94c54ea1efc12a8bc6b8","after":"37dd3997e5ddcf046dd8c36c70a2ea8f38846ca2","ref":"refs/heads/3.0.x","pushedAt":"2024-02-19T13:19:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"vglrun: Wordsmithing\n\n- The default value of VGL_DISPLAY is :0, not :0.0.\n\n- \"DRI device\" --> \"EGL device\" (because of\n  a1d485ae2307a22a1e24aa4c678aab73859cba5d)","shortMessageHtmlLink":"vglrun: Wordsmithing"}},{"before":"a7d6371369693cd32e4aee7aeab809d3ad68c7ef","after":"80a2b142bd0210960926da87de7460a77298df73","ref":"refs/heads/main","pushedAt":"2024-02-18T20:31:12.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"vglrun: Wordsmithing\n\n- The default value of VGL_DISPLAY is :0, not :0.0.\n\n- \"DRI device\" --> \"EGL device\" (because of\n  a1d485ae2307a22a1e24aa4c678aab73859cba5d)","shortMessageHtmlLink":"vglrun: Wordsmithing"}},{"before":"ba9ccdda83aae292599ffa5cdd0f03b7eae34ab9","after":"f1aab09360bc061c876a94c54ea1efc12a8bc6b8","ref":"refs/heads/3.0.x","pushedAt":"2024-02-18T20:31:12.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"vglrun: Wordsmithing\n\n- The default value of VGL_DISPLAY is :0, not :0.0.\n\n- \"DRI device\" --> \"EGL device\" (because of\n  a1d485ae2307a22a1e24aa4c678aab73859cba5d)","shortMessageHtmlLink":"vglrun: Wordsmithing"}},{"before":"83a884bc6a6c08b9be390b12dc53a42edb69b691","after":"a7d6371369693cd32e4aee7aeab809d3ad68c7ef","ref":"refs/heads/main","pushedAt":"2024-02-16T21:18:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"EGLX/eglSwapBuffers(): Flush context before swap\n\nThe documentation for eglSwapBuffers() states that \"eglSwapBuffers\nperforms an implicit flush operation on the context ... bound to surface\nbefore swapping.\"  The GLX front end uses double-buffered Pbuffers to\nemulate double-buffered windows, so it calls the real glXSwapBuffers()\nfunction to swap the buffers, and the real glXSwapBuffers() function\nensures that OpenGL rendering has completed.  However, EGL Pbuffer\nsurfaces are always single-buffered, so it would be useless for the\nEGL/X11 front end to call the real eglSwapBuffers() function.  Thus, we\nhave to emulate it.  glFlush() is asynchronous whereas glFinish() is\nsynchronous, so we need to call glFinish() if the current surface is\nbeing swapped.  This fixes a flickering issue that occurred with recent\nversions of Firefox.","shortMessageHtmlLink":"EGLX/eglSwapBuffers(): Flush context before swap"}},{"before":"398e941653137443a662bc726d82a04012eb5ea1","after":"83a884bc6a6c08b9be390b12dc53a42edb69b691","ref":"refs/heads/main","pushedAt":"2024-02-16T15:39:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"GNUInstallDirs.cmake: Various improvements\n\n- Integrate\n  https://github.com/Kitware/CMake/commit/c07bba27302960fc2f35b6a9e00eab8b32ca9a49#diff-1e2deb5301e9481203102fcddd1b2d0d2bf0ddc1cbb445c7f4b6414a3b869ce8\n  so that the default man directory is <CMAKE_INSTALL_PREFIX>/share/man\n  on FreeBSD systems.\n\n- For good measure, integrate\n  https://github.com/Kitware/CMake/commit/f835f189aeb38a791ad09ba5c2d89300a3fd16f1\n  so that the default info directory is\n  <CMAKE_INSTALL_PREFIX>/share/info on FreeBSD systems, even though we\n  don't use that directory.\n\n- Automatically set the CMake variable type to PATH for any\n  user-specified CMAKE_INSTALL_*DIR variables.","shortMessageHtmlLink":"GNUInstallDirs.cmake: Various improvements"}},{"before":"c6de170049330eefa1840fba6a15c0ea1dae8bdf","after":"ba9ccdda83aae292599ffa5cdd0f03b7eae34ab9","ref":"refs/heads/3.0.x","pushedAt":"2024-02-16T15:39:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"GNUInstallDirs.cmake: Various improvements\n\n- Integrate\n  https://github.com/Kitware/CMake/commit/c07bba27302960fc2f35b6a9e00eab8b32ca9a49#diff-1e2deb5301e9481203102fcddd1b2d0d2bf0ddc1cbb445c7f4b6414a3b869ce8\n  so that the default man directory is <CMAKE_INSTALL_PREFIX>/share/man\n  on FreeBSD systems.\n\n- For good measure, integrate\n  https://github.com/Kitware/CMake/commit/f835f189aeb38a791ad09ba5c2d89300a3fd16f1\n  so that the default info directory is\n  <CMAKE_INSTALL_PREFIX>/share/info on FreeBSD systems, even though we\n  don't use that directory.\n\n- Automatically set the CMake variable type to PATH for any\n  user-specified CMAKE_INSTALL_*DIR variables.","shortMessageHtmlLink":"GNUInstallDirs.cmake: Various improvements"}},{"before":"e870c9eb3c5ab8d7e053d4461c119d41b768c175","after":"c6de170049330eefa1840fba6a15c0ea1dae8bdf","ref":"refs/heads/3.0.x","pushedAt":"2024-02-16T14:59:47.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Faker: Thwart GTK's X visual cache\n\nStarting with\nhttps://github.com/GNOME/gtk/commit/dae447728db32a5a7162d9216f2e2343837cbae4\n(v3.15.2) and ending with\nhttps://github.com/GNOME/gtk/commit/1c55b32879e8eb4a6aa467ea4be688db995952c4\n(v4.3.2), GTK used glXGetConfig() to probe the OpenGL rendering\nattributes of all X visuals, it picked \"system\" (opaque) and \"RGBA\"\n(transparent) visuals based on those attributes, and it expected to find\na GLX FB config with a GLX_VISUAL_ID attribute corresponding to one of\nthose visuals.  (The purpose of this was to ensure that GTK windows can\nalways be used for OpenGL rendering, since the decision to enable OpenGL\nrendering may occur after the window is created.)\n\nStarting with\nhttps://github.com/GNOME/gtk/commit/8c7623de84d13437e951d37ded04dbefdea5c88c\n(GTK v3.15.2) and ending with\nhttps://github.com/GNOME/gtk/commit/62bac44a2108ceadbf659ce56f64bf14429fc5d2\n(GTK v4.3.2), GTK cached the system and RGBA visual IDs in an X root\nwindow property to avoid re-picking the visuals every time GTK was\ninitialized on a particular X display.\n\nThese mechanisms only worked reliably if there was a 1:1 correspondence\nbetween 2D X server visuals and GLX FB configs, which isn't the case\nwith VirtualGL.  More specifically, if GTK was initialized on the 2D X\nserver without VirtualGL, then GTK used the 2D X server's GLX\nimplementation to probe the OpenGL rendering attributes of the 2D X\nserver visuals.  That caused GTK to pick and cache different visuals\nthan it would have picked had VirtualGL been active, and it was likely\nthat none of the GLX FB configs returned by VirtualGL had a\nGLX_VISUAL_ID attribute corresponding to one of those visuals.\n\nThe easiest workaround is for the VirtualGL Faker to delete the\nGDK_VISUALS X root window property in the body of XOpenDisplay(), thus\nforcing GTK to re-pick the system and RGBA visuals using VirtualGL's\ninterposed version of glXGetConfig().\n\nFixes #158","shortMessageHtmlLink":"Faker: Thwart GTK's X visual cache"}},{"before":"ca6dcfaa4c73b8d657b830b9803f188b027dab06","after":"398e941653137443a662bc726d82a04012eb5ea1","ref":"refs/heads/main","pushedAt":"2024-02-15T20:28:09.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Faker: Thwart GTK's X visual cache\n\nStarting with\nhttps://github.com/GNOME/gtk/commit/dae447728db32a5a7162d9216f2e2343837cbae4\n(v3.15.2) and ending with\nhttps://github.com/GNOME/gtk/commit/1c55b32879e8eb4a6aa467ea4be688db995952c4\n(v4.3.2), GTK used glXGetConfig() to probe the OpenGL rendering\nattributes of all X visuals, it picked \"system\" (opaque) and \"RGBA\"\n(transparent) visuals based on those attributes, and it expected to find\na GLX FB config with a GLX_VISUAL_ID attribute corresponding to one of\nthose visuals.  (The purpose of this was to ensure that GTK windows can\nalways be used for OpenGL rendering, since the decision to enable OpenGL\nrendering may occur after the window is created.)\n\nStarting with\nhttps://github.com/GNOME/gtk/commit/8c7623de84d13437e951d37ded04dbefdea5c88c\n(GTK v3.15.2) and ending with\nhttps://github.com/GNOME/gtk/commit/62bac44a2108ceadbf659ce56f64bf14429fc5d2\n(GTK v4.3.2), GTK cached the system and RGBA visual IDs in an X root\nwindow property to avoid re-picking the visuals every time GTK was\ninitialized on a particular X display.\n\nThese mechanisms only worked reliably if there was a 1:1 correspondence\nbetween 2D X server visuals and GLX FB configs, which isn't the case\nwith VirtualGL.  More specifically, if GTK was initialized on the 2D X\nserver without VirtualGL, then GTK used the 2D X server's GLX\nimplementation to probe the OpenGL rendering attributes of the 2D X\nserver visuals.  That caused GTK to pick and cache different visuals\nthan it would have picked had VirtualGL been active, and it was likely\nthat none of the GLX FB configs returned by VirtualGL had a\nGLX_VISUAL_ID attribute corresponding to one of those visuals.\n\nThe easiest workaround is for the VirtualGL Faker to delete the\nGDK_VISUALS X root window property in the body of XOpenDisplay(), thus\nforcing GTK to re-pick the system and RGBA visuals using VirtualGL's\ninterposed version of glXGetConfig().\n\nFixes #158","shortMessageHtmlLink":"Faker: Thwart GTK's X visual cache"}},{"before":"f3a9c0a7eebb4600bb10bcf01f8e66a401344435","after":"ca6dcfaa4c73b8d657b830b9803f188b027dab06","ref":"refs/heads/main","pushedAt":"2023-12-15T17:16:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"dcommander","name":"DRC","path":"/dcommander","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/651941?s=80&v=4"},"commit":{"message":"Build/DEB dependencies: libegl1-mesa --> libegl1\n\nSince Ubuntu 18.04, the EGL libraries have been distributed in a package\nnamed libegl1, and libegl1-mesa has been a transitional dummy package\nthat points to libegl1.  In Ubuntu 23.10, the transitional dummy package\nwas removed, which caused a dependency error when attempting to install\nan official VirtualGL package.  Ubuntu 16.04 LTS was the last Ubuntu\nrelease supported by VirtualGL that didn't have a libegl1 package, and\nit has been EOL since 2021.  (Ubuntu 18.04 LTS is now EOL as well, as of\nearlier this year.)  Thus, we can safely change our package dependency\nfrom libegl1-mesa to libegl1.\n\nFixes #242","shortMessageHtmlLink":"Build/DEB dependencies: libegl1-mesa --&gt; libegl1"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEhB1vKgA","startCursor":null,"endCursor":null}},"title":"Activity · VirtualGL/virtualgl"}