fix(desktop): WebKitGTK fast-path on hybrid GPUs, + compile the Tauri crate in CI - #170
Merged
Conversation
…Linux The desktop app is slow on an ordinary Linux desktop-with-a-GPU, and it looks like a weak machine rather than a bug. WebKitGTK hands rendered frames to the compositor as DMA-BUFs. When the box has two DRM devices - an Intel iGPU driving `modesetting` alongside a discrete NVIDIA card - the import fails and WebKit quietly falls back instead of surfacing an error. The window still draws, so the only symptom is that everything feels heavy. Measured on an RTX 5060 Ti + HD 530, X11, WebKitGTK 2.52.3, idle window at 3840x2160: the web process burns 2.7-14.3% CPU with the renderer enabled and 0.0% with it disabled. Hardware GL was fine throughout (direct rendering yes, OpenGL 4.6) - the GPU was never the problem, the buffer handoff was. Set only when the operator has expressed no preference, so anyone whose stack handles DMA-BUF properly can opt back in with WEBKIT_DISABLE_DMABUF_RENDERER=0. Also adds a `cargo check` job, because nothing in CI compiles this crate today: release.yml builds it, but only on a `v*` tag, so a Rust change can sit on main until someone tries to cut installers and discovers it there. This commit would itself have been unverified without it.
They are a matched pair, but `next` is a production dependency and `eslint-config-next` is a development one, so grouping by dependency-type proposes them in two PRs that cannot pass independently: eslint-config-next 16 pulls eslint 10 and expects next 16, while eslint 10 removed the eslintrc API that `next lint` from next 15 still calls. That is not hypothetical. PR #161 merged the development half on its own and lint stopped running entirely - "Unknown options: useEslintrc" before it read a file - and stayed broken until the pair was pinned back. The two currently-open dependabot PRs are the same shape: #167 would take eslint to 10 and eslint-config-next to 16 while next stays on 15. Dependabot puts a dependency in the first group it matches, so listing the trio first keeps them together and makes the upgrade a single reviewable change that either works or doesn't.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Jul 29, 2026
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
1 participant
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.
Two independent fixes that missed the #169 merge window.
The desktop app feels slow, and it isn't the machine
WebKitGTK hands rendered frames to the compositor as DMA-BUFs. On a box with two DRM devices — an Intel iGPU driving
modesettingnext to a discrete NVIDIA card, i.e. an ordinary desktop with a GPU — that import fails and WebKit quietly drops to a fallback path instead of raising an error. The window still draws, so the only symptom is that everything feels heavy.Measured on an RTX 5060 Ti + HD 530, X11, WebKitGTK 2.52.3, idle window at 3840×2160:
WEBKIT_DISABLE_DMABUF_RENDERER=1Hardware GL was healthy throughout (
direct rendering: Yes, OpenGL 4.6, RTX 5060 Ti) — the GPU was never the bottleneck, the buffer handoff was.Set only when the operator has expressed no preference, so anyone whose stack handles DMA-BUF correctly can opt back in with
WEBKIT_DISABLE_DMABUF_RENDERER=0.Nothing in CI compiles the Tauri crate
release.ymlbuilds it, but only on av*tag — so a Rust change can sit on main for weeks and first break when you try to cut installers. Adds acargo checkjob (the cheap half of that build: type- and borrow-check, no linking or bundling). The Rust change above would otherwise have merged unverified.Dependabot keeps proposing an upgrade that cannot pass
nextis a production dependency andeslint-config-nextis a development one, so grouping bydependency-typesplits a version-locked pair across two PRs. Neither works alone: eslint-config-next 16 pulls eslint 10 and expects next 16, while eslint 10 removed the eslintrc API thatnext lintfrom next 15 still calls.That already happened — #161 merged the development half and left lint unrunnable until #168 pinned it back — and #167 was queued to do it again (closed, with the reasoning on the PR). Grouping the trio first means the upgrade arrives as one reviewable change that either works or doesn't.