Short summary
The Linux AppImage resets an explicit WEBKIT_DISABLE_DMABUF_RENDERER=0 override to 1 in its WebKit child, preventing an accelerated-rendering comparison while investigating sluggish UI interaction.
Affected version or release
1.1.16 (Linux x86_64 AppImage)
Installation context
Local Linux desktop, native X11 session (not XWayland); NVIDIA proprietary driver 580.178.04. Bundled WebKitGTK 2.50.4; system WebKitGTK 2.52.6.
What happened?
This was generated by AI during triage.
The app feels sluggish during basic typing, scrolling, and clicking. While investigating, a controlled relaunch was performed with:
env WEBKIT_DISABLE_DMABUF_RENDERER=0 ./GitHub-Copilot-linux-x64.AppImage
Inspection of only this environment variable in the running processes showed:
App process: WEBKIT_DISABLE_DMABUF_RENDERER=0
WebKitWebProcess: WEBKIT_DISABLE_DMABUF_RENDERER=1
The startup/child-launch path therefore resets the explicit caller-supplied value. The app opens successfully, but the attempted accelerated comparison does not actually change the renderer configuration.
The ignored override is directly reproduced. Its contribution to the responsiveness problem is a strong hypothesis, not a verified before/after result.
Steps to reproduce
-
Fully exit the app so an existing instance cannot handle the launch.
-
Launch the 1.1.16 Linux AppImage with:
env WEBKIT_DISABLE_DMABUF_RENDERER=0 ./GitHub-Copilot-linux-x64.AppImage
-
Identify the app process and its WebKitWebProcess child.
-
Inspect only WEBKIT_DISABLE_DMABUF_RENDERER in each process's /proc/PID/environ, substituting the appropriate process ID locally. Do not dump or share the full environment.
-
Observe 0 in the app's original environment and 1 in the renderer's environment.
-
Interact with the UI by typing, scrolling, and clicking. The renderer still receives the disabling flag, so this launch cannot serve as a valid hardware-acceleration A/B test.
No repository-specific content is required to reproduce the environment override.
Expected behavior
Respect an explicit rendering override, or provide a supported, documented diagnostic opt-in.
If the disabling flag is required for a known driver compatibility issue, retain safe defaults while explaining the restriction and whether an override is supported.
This report is not requesting that acceleration be enabled indiscriminately on configurations where it is known to fail.
Additional context
Sanitized performance observations
- During an initial post-launch interaction capture, the WebKit main UI thread used approximately 84-100% of one CPU core over five consecutive roughly two-second intervals, with little scheduler waiting.
- A subsequent 20-second userspace CPU profile collected 373 samples. Approximately 94.1% of sampled CPU time was on the main UI thread.
- Sampled CPU distribution: 47.5% WebKit, 36.2% JavaScriptCore/JIT, 6.7% fontconfig, and 0.8% NVIDIA EGL driver. These are shares of sampled CPU time, not whole-machine utilization or measurements of GPU execution time.
- No machine-wide CPU, memory, or GPU-capacity bottleneck was observed. Activity fell substantially after the UI settled.
- Four instrumented terminal input-to-paint measurements within the later capture were 20-33 ms. This does not establish severe latency for every interaction, and it does not measure time waiting before the application's input handler runs.
The profile supports investigating frontend/rendering work, but does not prove that the flag explains all reported lag. Missing native debug symbols also limit function-level attribution.
Relevant upstream behavior
In bundled WebKitGTK 2.50.4, WEBKIT_DISABLE_DMABUF_RENDERER=1 makes rendererBufferTransportMode() return an empty mode set, so checkRequirements() returns false. HardwareAccelerationManager then disables hardware acceleration:
Related reports
No raw logs, profiler files, screenshots, conversation content, credentials, account identifiers, actual process/session IDs, machine names, local filesystem paths, or private repository details are attached.
Short summary
The Linux AppImage resets an explicit WEBKIT_DISABLE_DMABUF_RENDERER=0 override to 1 in its WebKit child, preventing an accelerated-rendering comparison while investigating sluggish UI interaction.
Affected version or release
1.1.16 (Linux x86_64 AppImage)
Installation context
Local Linux desktop, native X11 session (not XWayland); NVIDIA proprietary driver 580.178.04. Bundled WebKitGTK 2.50.4; system WebKitGTK 2.52.6.
What happened?
The app feels sluggish during basic typing, scrolling, and clicking. While investigating, a controlled relaunch was performed with:
Inspection of only this environment variable in the running processes showed:
The startup/child-launch path therefore resets the explicit caller-supplied value. The app opens successfully, but the attempted accelerated comparison does not actually change the renderer configuration.
The ignored override is directly reproduced. Its contribution to the responsiveness problem is a strong hypothesis, not a verified before/after result.
Steps to reproduce
Fully exit the app so an existing instance cannot handle the launch.
Launch the 1.1.16 Linux AppImage with:
Identify the app process and its
WebKitWebProcesschild.Inspect only
WEBKIT_DISABLE_DMABUF_RENDERERin each process's/proc/PID/environ, substituting the appropriate process ID locally. Do not dump or share the full environment.Observe
0in the app's original environment and1in the renderer's environment.Interact with the UI by typing, scrolling, and clicking. The renderer still receives the disabling flag, so this launch cannot serve as a valid hardware-acceleration A/B test.
No repository-specific content is required to reproduce the environment override.
Expected behavior
Respect an explicit rendering override, or provide a supported, documented diagnostic opt-in.
If the disabling flag is required for a known driver compatibility issue, retain safe defaults while explaining the restriction and whether an override is supported.
This report is not requesting that acceleration be enabled indiscriminately on configurations where it is known to fail.
Additional context
Sanitized performance observations
The profile supports investigating frontend/rendering work, but does not prove that the flag explains all reported lag. Missing native debug symbols also limit function-level attribution.
Relevant upstream behavior
In bundled WebKitGTK 2.50.4, WEBKIT_DISABLE_DMABUF_RENDERER=1 makes rendererBufferTransportMode() return an empty mode set, so checkRequirements() returns false. HardwareAccelerationManager then disables hardware acceleration:
Related reports
No raw logs, profiler files, screenshots, conversation content, credentials, account identifiers, actual process/session IDs, machine names, local filesystem paths, or private repository details are attached.