Fix blank Linux app window by disabling WebKitGTK DMABUF renderer#44
Open
debanjum wants to merge 1 commit into
Open
Fix blank Linux app window by disabling WebKitGTK DMABUF renderer#44debanjum wants to merge 1 commit into
debanjum wants to merge 1 commit into
Conversation
WebKitGTK 2.42+ defaults to a DMA-BUF based renderer (and accelerated compositing) that fails to produce a first paint on many Linux GPU stacks, leaving a blank/white window that only a manual reload recovers. This is the cross-distro blank-screen reported in #21 and matches upstream tauri-apps/tauri#13885 and #9394. Force the legacy rendering paths at startup, before GTK/WebKit initialize, by setting both WEBKIT_DISABLE_DMABUF_RENDERER=1 and WEBKIT_DISABLE_COMPOSITING_MODE=1 — the accepted workaround disables both together, since the compositing failure produces the same blank window on X11 ("AcceleratedSurfaceDMABuf was unable to construct a complete framebuffer") that the DMA-BUF flag alone misses. Each is set only when unset so a user can still override it. Scoped to Linux; no effect on macOS/Windows. This addresses the rendering layer only. The separate "Could not create default EGL display: EGL_BAD_PARAMETER" failure seen on some distros is a GPU-library-bundling problem (the AppImage shipping the build host's mesa/libEGL/libwayland) and needs a follow-up to exclude those host libraries from the bundle.
debanjum
force-pushed
the
fix-linux-blank-screen-dmabuf
branch
from
May 29, 2026 18:14
682129d to
aee4647
Compare
Contributor
|
I am getting the same behavior as before sadly. I'm getting the same errors, including |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Set both
WEBKIT_DISABLE_DMABUF_RENDERER=1andWEBKIT_DISABLE_COMPOSITING_MODE=1at startup (Linux only, before GTK/WebKit initialize) to force WebKitGTK's legacy rendering paths.Why
WebKitGTK 2.42+ defaults to a DMA-BUF based GPU renderer (and accelerated compositing) that fails to produce a first paint on many Linux GPU stacks — notably Arch and other non-Ubuntu/Debian setups. The window comes up blank/white and only a manual reload recovers it. This is the cross-distro blank-screen reported in #21, matching upstream tauri-apps/tauri#13885 and #9394.
The accepted community workaround (e.g. Tolaria, yaak) disables both paths together: the compositing failure produces the same blank window on X11 (
AcceleratedSurfaceDMABuf was unable to construct a complete framebuffer) that the DMA-BUF flag alone misses. The WebKitGTK maintainer (Igalia) endorsesWEBKIT_DISABLE_DMABUF_RENDERER=1as the first-line fix on WebKit Bugzilla #261874.Each var is set only when unset, so a user can still override it and it is scoped to Linux, so no effect on macOS/Windows.
Testing
cargo check).Scope / follow-up
This addresses the rendering layer of #21 only.
The
Could not create default EGL display: EGL_BAD_PARAMETERfailure is a distinct problem — the AppImage bundling the build host's GPU libraries (mesa/libEGL/libGL/libwayland) that clash with the target distro's drivers. These env var based changes do not fix that.If we still see
EGL_BAD_PARAMETER, the follow-up is to exclude/replace those host GPU libraries in the AppImage build (slots into the existingrepackAppImageWithPristineSidecarsstep), or pinlibwebkit2gtkto a known-good version.