[Linux AppImage 1.1.16] WEBKIT_DISABLE_DMABUF_RENDERER=0 is overridden; sluggish UI

Start at the Linux AppImage startup and WebKit child-launch path, then reproduce the filtered /proc/PID/environ check with WEBKIT_DISABLE_DMABUF_RENDERER=0. Done means the child respects an explicit rendering override, or the supported diagnostic opt-in and its safe-default restriction are documented; verify that the launch remains functional.

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

1. Fully exit the app so an existing instance cannot handle the launch.

2. Launch the 1.1.16 Linux AppImage with:

   env WEBKIT_DISABLE_DMABUF_RENDERER=0 ./GitHub-Copilot-linux-x64.AppImage
   

3. Identify the app process and its WebKitWebProcess child.

4. 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.

5. Observe 0 in the app's original environment and 1 in the renderer's environment.

6. 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:

• https://github.com/WebKit/WebKit/blob/webkitgtk-2.50.4/Source/WebKit/UIProcess/gtk/AcceleratedBackingStore.cpp#L82-L145
• https://github.com/WebKit/WebKit/blob/webkitgtk-2.50.4/Source/WebKit/UIProcess/gtk/HardwareAccelerationManager.cpp

Related reports

• https://github.com/github/app/issues/3060 discusses AppImage packaging, Wayland, and this flag. This report adds a 1.1.16 NVIDIA/native-X11 reproduction where the explicit 0 override is changed to 1 in the child process. The packaging workaround described there was not tested here.
• https://github.com/github/app/issues/335 describes an older home-page WebKit high-CPU issue.

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.