[GH-ISSUE #273] Linux: forced SwiftShader causes delayed hover feedback and high CPU usage on Intel Iris Xe #175

New issue

Open

opened 2026-10-18 14:06:44 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 14:06:44 +00:00

Owner

Originally created by @hirntot on GitHub (Sep 18, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/273

Problem

Open WebUI Desktop 0.0.20 forces SwiftShader on Linux. On a system with Intel Iris Xe graphics, the remote web UI becomes noticeably sluggish: hover effects appear well after the pointer has moved away. The same service feels responsive in a Firefox-based web app.

After removing only the two forced graphics-backend switches from a separate test copy, while keeping the existing user profile and the renderer sandbox fix from #272, the user reported that interaction was much better.

Environment

LMDE 7 (Debian-based Linux), amd64
Intel TigerLake-LP GT2 / Iris Xe Graphics
Desktop 0.0.20, native DEB installation; X11 backend observed in the GPU process
Remote Open WebUI instance (server version 0.11.3)
Baseline already includes the one-line sandbox fix proposed in #272; that resolves the blank webview but leaves this performance issue

Reproduction

Launch the desktop app on the above environment and open a remote connection.
Move the pointer across interactive controls and observe delayed hover feedback.
Compare a copy of the same application with the existing profile, retaining the sandbox fix, but removing the two graphics switches shown below.
Interaction becomes substantially more responsive without changing the server.

Observations

Baseline GPU process arguments include --use-gl=angle --use-angle=swiftshader.
The test copy no longer has either forced switch in its GPU process arguments.
The GPU process's lifetime-average CPU utilization reported by ps was approximately 76% in the baseline observation and 8% in the test observation. These samples have different process lifetimes and workloads; they are supporting observations, not a controlled benchmark or a measured speedup.
The test log contains no shared-memory allocation failures. It still contains an NSS root-certificate error and the GPU sandbox initialization warning; this is not a claim of an entirely warning-free run.
The actual selected rendering backend was not queried with getGPUInfo(), so hardware acceleration is not independently confirmed. The verified change is removal of forced SwiftShader, together with the user's improved responsiveness.

Proposed fix

Let Electron/Chromium choose the graphics backend by default instead of unconditionally selecting software rendering on every Linux system:

 if (process.platform === 'linux') {
   // Other existing Linux workarounds remain unchanged.
-  app.commandLine.appendSwitch('use-gl', 'angle')
-  app.commandLine.appendSwitch('use-angle', 'swiftshader')
 }

This was the only runtime change relative to the working sandbox-patched baseline. The existing GPU sandbox workaround and shared-memory setting were retained.

SwiftShader was introduced to address real Linux GPU/compositing failures (#178, #157). Rather than deleting that fallback entirely, consider exposing it as an explicit compatibility option or selecting it after a confirmed GPU initialization failure. A default change should be checked on the configurations that originally required the workaround, including other GPUs and package formats.

Validation and scope

The user confirmed the improvement in a separate patched app using their existing profile on the machine above. A new unofficial DEB containing these exact tested app bytes was built and its payload verified; installation of that second DEB has not yet been confirmed. Other GPU vendors, distributions, Wayland and AppImage/snap/Flatpak were not tested.

Related: #272 fixes the separate blank-webview sandbox failure and deliberately does not include this graphics change.

Originally created by @hirntot on GitHub (Sep 18, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/273 ## Problem Open WebUI Desktop 0.0.20 forces SwiftShader on Linux. On a system with Intel Iris Xe graphics, the remote web UI becomes noticeably sluggish: hover effects appear well after the pointer has moved away. The same service feels responsive in a Firefox-based web app. After removing only the two forced graphics-backend switches from a separate test copy, while keeping the existing user profile and the renderer sandbox fix from #272, the user reported that interaction was much better. ## Environment - LMDE 7 (Debian-based Linux), amd64 - Intel TigerLake-LP GT2 / Iris Xe Graphics - Desktop 0.0.20, native DEB installation; X11 backend observed in the GPU process - Remote Open WebUI instance (server version 0.11.3) - Baseline already includes the one-line sandbox fix proposed in #272; that resolves the blank webview but leaves this performance issue ## Reproduction 1. Launch the desktop app on the above environment and open a remote connection. 2. Move the pointer across interactive controls and observe delayed hover feedback. 3. Compare a copy of the same application with the existing profile, retaining the sandbox fix, but removing the two graphics switches shown below. 4. Interaction becomes substantially more responsive without changing the server. ## Observations - Baseline GPU process arguments include `--use-gl=angle --use-angle=swiftshader`. - The test copy no longer has either forced switch in its GPU process arguments. - The GPU process's lifetime-average CPU utilization reported by `ps` was approximately 76% in the baseline observation and 8% in the test observation. These samples have different process lifetimes and workloads; they are supporting observations, **not a controlled benchmark or a measured speedup**. - The test log contains no shared-memory allocation failures. It still contains an NSS root-certificate error and the GPU sandbox initialization warning; this is not a claim of an entirely warning-free run. - The actual selected rendering backend was not queried with `getGPUInfo()`, so hardware acceleration is not independently confirmed. The verified change is removal of forced SwiftShader, together with the user's improved responsiveness. ## Proposed fix Let Electron/Chromium choose the graphics backend by default instead of unconditionally selecting software rendering on every Linux system: ```diff if (process.platform === 'linux') { // Other existing Linux workarounds remain unchanged. - app.commandLine.appendSwitch('use-gl', 'angle') - app.commandLine.appendSwitch('use-angle', 'swiftshader') } ``` This was the only runtime change relative to the working sandbox-patched baseline. The existing GPU sandbox workaround and shared-memory setting were retained. SwiftShader was introduced to address real Linux GPU/compositing failures (#178, #157). Rather than deleting that fallback entirely, consider exposing it as an explicit compatibility option or selecting it after a confirmed GPU initialization failure. A default change should be checked on the configurations that originally required the workaround, including other GPUs and package formats. ## Validation and scope The user confirmed the improvement in a separate patched app using their existing profile on the machine above. A new unofficial DEB containing these exact tested app bytes was built and its payload verified; installation of that second DEB has not yet been confirmed. Other GPU vendors, distributions, Wayland and AppImage/snap/Flatpak were not tested. Related: #272 fixes the separate blank-webview sandbox failure and deliberately does not include this graphics change.

bsakaguchi commented

2026-10-18 14:06:45 +00:00

Author

Owner

@marc-mrt commented on GitHub (Sep 27, 2026):

Same issue here, on a configuration the original report lists as untested: AMD + Wayland + Flatpak. Removing the forced SwiftShader switch fixes it, and <webview> compositing keeps working.

Environment

Arch Linux, kernel 7.2.6, Hyprland 0.56.2 (Wayland)
AMD Radeon RX 7900 XTX (Navi 31, amdgpu), plus a Raphael iGPU; Chromium used renderD128 (the 7900 XTX)
Open WebUI Desktop 0.0.20 (Electron 39.8.2 / Chrome 142.0.7444.265), Flatpak com.openwebui.desktop, runtime org.freedesktop.Platform//23.08, Mesa 25.0.7 (org.freedesktop.Platform.GL.default)
Remote Open WebUI server connection
main (0931b46) still has the same two switches in src/main/index.ts, so this still applies to the latest code.

Observations

Baseline: the GPU process runs with --use-gl=angle --use-angle=swiftshader and maps libvk_swiftshader.so. It used about 65–185% CPU during normal use, and the UI was very sluggish.
The switch can't be overridden from the command line. flatpak run com.openwebui.desktop --use-angle=gl (and =vulkan, =default) still produces a GPU process with --use-angle=swiftshader. app.commandLine.appendSwitch() runs after argv is parsed, and Chromium keeps the last value for a repeated switch. So users currently have no workaround short of patching app.asar.
Patched copy: I renamed the use-angle switch in app.asar (a same-length byte patch to xse-angle, which Chromium ignores) and kept everything else, including use-gl=angle, disable-gpu-sandbox, no-sandbox and disable-dev-shm-usage. The GPU process then starts with only --use-gl=angle, maps Mesa's libgallium-25.0.7.so and no SwiftShader, and used about 5% CPU in a short idle sample. Remote connection views render normally, with no blank webview, and the app is responsive with my existing profile.
No GPU-process crash and no fallback to SwiftShader in the patched run. The logs showed nothing beyond the usual D-Bus/Wayland warnings.

These CPU numbers are ps samples, not a controlled benchmark.

Suggestion

This supports the direction in the original report: default to Chromium's own backend choice, and use SwiftShader only as a fallback. Chromium already has its own fallback path when hardware GL init fails. If the explicit fallback is still needed for #119 / #157 / #178, it could reuse the existing GPU-crash marker logic, which already relaunches after a GPU process crash. At minimum, an opt-out would help, for example an env var or config key checked before the appendSwitch calls, since command-line flags can't override it today:

-  app.commandLine.appendSwitch('use-gl', 'angle')
-  app.commandLine.appendSwitch('use-angle', 'swiftshader')
+  if (process.env.OPEN_WEBUI_DESKTOP_SOFTWARE_GL === '1' || gpuSandboxDisabled) {
+    app.commandLine.appendSwitch('use-gl', 'angle')
+    app.commandLine.appendSwitch('use-angle', 'swiftshader')
+  }

(gpuSandboxDisabled is only a sketch of "a GPU crash already happened". It is defined after this block today, so the ordering would need adjusting.)

Happy to test a build on this setup.

@marc-mrt commented on GitHub (Sep 27, 2026): Same issue here, on a configuration the original report lists as untested: **AMD + Wayland + Flatpak**. Removing the forced SwiftShader switch fixes it, and `<webview>` compositing keeps working. ## Environment - Arch Linux, kernel 7.2.6, Hyprland 0.56.2 (Wayland) - AMD Radeon RX 7900 XTX (Navi 31, `amdgpu`), plus a Raphael iGPU; Chromium used `renderD128` (the 7900 XTX) - Open WebUI Desktop 0.0.20 (Electron 39.8.2 / Chrome 142.0.7444.265), Flatpak `com.openwebui.desktop`, runtime `org.freedesktop.Platform//23.08`, Mesa 25.0.7 (`org.freedesktop.Platform.GL.default`) - Remote Open WebUI server connection - `main` (0931b46) still has the same two switches in `src/main/index.ts`, so this still applies to the latest code. ## Observations - Baseline: the GPU process runs with `--use-gl=angle --use-angle=swiftshader` and maps `libvk_swiftshader.so`. It used about 65–185% CPU during normal use, and the UI was very sluggish. - **The switch can't be overridden from the command line.** `flatpak run com.openwebui.desktop --use-angle=gl` (and `=vulkan`, `=default`) still produces a GPU process with `--use-angle=swiftshader`. `app.commandLine.appendSwitch()` runs after argv is parsed, and Chromium keeps the last value for a repeated switch. So users currently have no workaround short of patching `app.asar`. - Patched copy: I renamed the `use-angle` switch in `app.asar` (a same-length byte patch to `xse-angle`, which Chromium ignores) and kept everything else, including `use-gl=angle`, `disable-gpu-sandbox`, `no-sandbox` and `disable-dev-shm-usage`. The GPU process then starts with only `--use-gl=angle`, maps Mesa's `libgallium-25.0.7.so` and no SwiftShader, and used about 5% CPU in a short idle sample. Remote connection views render normally, with no blank webview, and the app is responsive with my existing profile. - No GPU-process crash and no fallback to SwiftShader in the patched run. The logs showed nothing beyond the usual D-Bus/Wayland warnings. These CPU numbers are `ps` samples, not a controlled benchmark. ## Suggestion This supports the direction in the original report: default to Chromium's own backend choice, and use SwiftShader only as a fallback. Chromium already has its own fallback path when hardware GL init fails. If the explicit fallback is still needed for #119 / #157 / #178, it could reuse the existing GPU-crash marker logic, which already relaunches after a GPU process crash. At minimum, an opt-out would help, for example an env var or config key checked before the `appendSwitch` calls, since command-line flags can't override it today: ```diff - app.commandLine.appendSwitch('use-gl', 'angle') - app.commandLine.appendSwitch('use-angle', 'swiftshader') + if (process.env.OPEN_WEBUI_DESKTOP_SOFTWARE_GL === '1' || gpuSandboxDisabled) { + app.commandLine.appendSwitch('use-gl', 'angle') + app.commandLine.appendSwitch('use-angle', 'swiftshader') + } ``` (`gpuSandboxDisabled` is only a sketch of "a GPU crash already happened". It is defined after this block today, so the ordering would need adjusting.) Happy to test a build on this setup.

bsakaguchi referenced this issue

2026-10-18 14:07:10 +00:00

[PR #218] fix: allow OAuth popups to open inside Electron webview #230

bsakaguchi referenced this issue

2026-10-18 14:07:14 +00:00

[PR #269] fix: harden desktop shell against untrusted webviews and supply chain #237