Repository navigation
Conversation
packaging/flatpak/dev.testpattern.app.yml builds on the GNOME 51 runtime (GTK/WebKitGTK/libva/PipeWire from the runtime) with libass, libunibreak and uchardet as modules, the static media engine via scripts/build-media.sh on git sources pinned to its tags, and pinned Rust 1.99.0 / bun 1.4.2 as build-only modules. scripts/flatpak.sh builds, installs or bundles it (.deps/flatpak/testpattern.flatpak) and 'pins' checks the manifest against build-media.sh / rust-toolchain.toml / package.json. The app is built from the working tree with --frozen-lockfile/--locked, so this is a local/CI build, not a Flathub submission. CI builds the bundle for main, tags and manual runs and attaches it to releases (Flathub gnome-51 image). Verified locally: installed app starts in a nested KWin with a fresh profile and gets the mpv render context with VA-API zero-copy. Co-authored-by: Claude <noreply@anthropic.com>
The GNOME 51 runtime's WebKitGTK ran the web process away right after launch, idle: ~100% CPU and ~5.9 GB within a minute, until the OOM killer ended it (journal: 7.5 and 9.7 GB). Measured on Intel UHD 620 / Mesa with the same library in a nested KWin. WEBKIT_DISABLE_DMABUF_RENDERER=1 keeps it flat at ~239 MB (rebuilt Flatpak, 3 min). The native build on the system WebKitGTK 2.54.2 never showed it; mpv's video surface is separate and unaffected. Co-authored-by: Claude <noreply@anthropic.com>
Conflicts: - .github/workflows/ci.yml: kept main's tag-only `release` job (version gate, SHA256SUMS, Sigstore attestation, draft release). The `flatpak` job no longer publishes on its own; it uploads its bundle as the `testpattern-flatpak-x86_64` artifact, which `release` now needs, checksums and attaches. Release notes gain a Flatpak install line. - WORKLOG.md: kept both sides. Main took T-057 for the release pipeline, so the Flatpak work is renumbered T-059 (T-058 is the Chromecast work in progress) here, in the manifest, scripts/flatpak.sh and ci.yml. Checked: scripts/check.sh green on the merged tree (81 Rust tests, clippy, tsc, 43 vitest, notices), actionlint clean, flatpak.sh pins ok. Co-authored-by: Claude <noreply@anthropic.com>
df49b9cd
changed the title
WEBKIT_DISABLE_DMABUF_RENDERER=1 (82dc80e) kept memory flat but left the transparent webview black on the runtime's WebKitGTK 2.54: only repainted regions show, so hovered elements flash up and fade. It's removed. The runaway itself was bisected in a bare WebKitGTK window inside the GNOME 51 runtime (no Tauri, no mpv) serving the real UI and catalog. Two triggers, each enough on its own: - backdrop-filter on the small chips over poster artwork: the rating chip (media.tsx) and the 4K/DV quality badges (LibraryBrowser.tsx). Now plain dark backgrounds. - the .skeleton shimmer, an endless background-position animation, on a poster grid that is still loading (Movies: ~+1 GB/min). Now an opacity pulse (styles.css). Every other blur, animation and image was harmless. With runtime defaults, Home, Movies, Series, Live TV, Guide and Search each stay at ~265-290 MB for a minute (runtime WebKit, real data). The rebuilt Flatpak renders Home fully and stays at ~240 MB for 2 minutes. scripts/check.sh passes. Co-authored-by: Claude <noreply@anthropic.com>
df49b9cd
added a commit
that referenced
this pull request
Nov 3, 2026
Docs only: README and WORKLOG keep both the Chromecast (T-058) and Flatpak (T-059) entries. The Flatpak build runs build-media.sh, so it picks up the AAC encoder casting needs.
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
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.
packaging/flatpak/dev.testpattern.app.yml builds on the GNOME 51 runtime (GTK/WebKitGTK/libva/PipeWire from the runtime) with libass, libunibreak and uchardet as modules, the static media engine via scripts/build-media.sh on git sources pinned to its tags, and pinned Rust 1.99.0 / bun 1.4.2 as build-only modules. scripts/flatpak.sh builds, installs or bundles it (.deps/flatpak/testpattern.flatpak) and 'pins' checks the manifest against build-media.sh / rust-toolchain.toml / package.json. The app is built from the working tree with --frozen-lockfile/--locked, so this is a local/CI build, not a Flathub submission. Verified locally: installed app starts in a nested KWin with a fresh profile and gets the mpv render context with VA-API zero-copy.
CI: the
flatpakjob builds the bundle for main, tags and manual runs (Flathub gnome-51 image) and uploads it as thetestpattern-flatpak-x86_64artifact. On tags, main'sreleasejob (#9) now waits for it too and addstestpattern.flatpakto the checksummed, attested draft release with the other bundles. The release notes gain a Flatpak install line.Fix after first use (82dc80e, replaced by 4e05b98): the installed Flatpak's web process ran away right after launch, idle: ~100% CPU and ~5.9 GB within a minute, then OOM-killed (journal: 7.5 and 9.7 GB; Intel UHD 620 / Mesa). The first fix,
WEBKIT_DISABLE_DMABUF_RENDERER=1, kept memory flat but turned the transparent webview black on the runtime's WebKitGTK 2.54 (only repainted parts show, so hovered elements flash up and fade). 4e05b98 removes it and fixes the cause in the UI instead.I bisected the problem in a bare WebKitGTK window inside the GNOME 51 runtime, without Tauri or mpv, serving the real UI and catalog. Two triggers, each enough on its own:
backdrop-filteron the small chips over poster artwork: the rating chip (media.tsx) and the 4K/DV badges (LibraryBrowser.tsx). They now use plain dark backgrounds..skeletonshimmer, an endlessbackground-positionanimation, on a poster grid that is still loading (Movies grew ~1 GB/min). It's now an opacity pulse (styles.css).Every other blur, animation and image tested harmless. With runtime defaults, Home, Movies, Series, Live TV, Guide and Search each stayed at ~265–290 MB for a minute. The rebuilt Flatpak renders Home fully and stays at ~240 MB for 2 minutes. The native build on the system WebKitGTK 2.54.2 never showed either problem. Only measured on this one GPU.
Merged main (b93b7b2): #9 took T-057 for the release pipeline, so this work is now T-059 (T-058 is the Chromecast work in progress). In ci.yml, main's release job was kept and the Flatpak job stopped publishing on its own, as above. In WORKLOG.md both sides were kept. After the merge:
scripts/check.shpassed (81 Rust tests, clippy, tsc, 43 vitest, notices), actionlint is clean andflatpak.sh pinspasses. The tag path of the release job hasn't run yet.