fix(linux): bootstrap Flutter EGL on an isolated worker - #200
Merged
Conversation
nmfisher
force-pushed
the
fix/linux-egl-context-bootstrap
branch
from
August 20, 2026 06:34
b1dd7f6 to
caa1784
Compare
nmfisher
force-pushed
the
fix/linux-egl-context-bootstrap
branch
from
August 20, 2026 08:49
2e57bd2 to
021859b
Compare
This was referenced Aug 20, 2026
nmfisher
force-pushed
the
fix/linux-egl-context-bootstrap
branch
from
August 21, 2026 02:54
422128c to
a2cac9d
Compare
🤖 Generated with GitHub Actions
…s setToneMapper) (#267) * fix!: view-owned ColorGrading lifecycle, builder-only API Consolidates the color-grading work (previously a chain of commits on develop; rebased onto the FilamentApp engine-handle branch): - the view owns whichever ColorGrading is currently set: replacing, clearing, or destroying the view destroys the owned grading (fixes leaks on replace/clear/teardown) - ColorGrading and ColorGradingBuilder expose dispose() (scoped to unattached gradings / builder freeing); the builder is REUSABLE per Filament's pattern - build() does not consume it - ToneMapper dispose is idempotent, with the mapper-must-outlive-the- builder contract documented per Filament's header - removes View.setToneMapper, ThermionViewer.setToneMapper, the dead FilamentApp.createColorGrading, and the native ColorGrading_create / ColorGrading_createRenderThread C entry points (bindings regenerated) - docstring examples fixed (ToneMapper.ACES never existed); web_gallery example corrected (was double-freeing the replaced grading) - tests cover the full lifecycle: destroy-on-replace, clear-and-destroy, teardown, abandoned-builder dispose, double-dispose no-ops, use-after-dispose throwing, builder reuse with mutate-between-builds Co-Authored-By: Claude <noreply@anthropic.com> * docs: contract docstrings live on interfaces, not FFI impls FFIColorGrading.dispose, FFIColorGradingBuilder.build, and the FFIToneMapper factories duplicated docstrings that already exist on the abstract ColorGrading, ColorGradingBuilder, and ToneMapper interfaces. The duplicates had also started to drift from the interface wording. The interface layer is the public API surface (the FFI statics are reachable but secondary), so it owns the contract documentation; the implementations keep only their one-line class markers. Co-Authored-By: Claude <noreply@anthropic.com> * docs: setColorGrading - one view per ColorGrading Each view destroys the grading it owns, so sharing an instance across views dangling-pointers the second view. Document the restriction and the supported pattern (build one grading per view; the reusable builder makes that cheap). Co-Authored-By: Claude <noreply@anthropic.com> * feat: share one ColorGrading across multiple views Filament permits attaching a single ColorGrading to several views, so replace exclusive view ownership with collective ownership: - each attach registers a per-view reference; detaching (replace, clear, or view destruction - always after the dissociating native set/clear, per Filament's dissociate-before-destroy rule) releases it, and the native grading is destroyed when the last view detaches - ColorGrading.dispose() destroys an unattached grading immediately and defers destruction while any view is still attached (instead of being forbidden) - one view releasing a grading never affects other views still using it New tests: a grading shared by two views survives the first view detaching (captured on the second to prove it), and dispose-while- attached defers until the last detach. Co-Authored-By: Claude <noreply@anthropic.com> * chore: update generated artifacts + format (CI) 🤖 Generated with GitHub Actions * refactor!: caller-managed ColorGrading lifecycle, no refcounting Filament's contract: View::setColorGrading performs no ownership transfer and no reference counting; a grading must be dissociated from all views before it is destroyed. Thermion now requires the same manual lifecycle instead of tracking attachments internally: - FFIColorGrading: drop the view-count/deferred-dispose machinery; dispose() destroys the native grading immediately (idempotent). - FFIView: setColorGrading is a plain non-owning forward; the view no longer tracks or releases the grading on replace/clear/destroy. - Docs on ColorGrading/setColorGrading/getColorGrading state the caller-managed contract, including multi-view sharing and the non-owning getColorGrading wrapper (never dispose it). - Tests reworked for dissociate-then-dispose; the deferred-dispose test is replaced by a dispose-idempotency test. Test helpers track gradings they attach and dispose them after the viewer is destroyed. - web_gallery effects controls dispose the replaced/cleared grading. Co-Authored-By: Claude <noreply@anthropic.com> * Update CHANGELOG.md --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
- TEMPORARY push trigger on this branch while under test on the self-hosted runner; remove before merging. - Fall back to :0 when the x11-display input is absent (push events have no inputs context, which would otherwise blank DISPLAY). - Distro-aware dependency step: keep apt-get for Ubuntu, add a dnf path for Fedora that no-ops when deps are preinstalled and sudo needs a password. Co-Authored-By: Claude <noreply@anthropic.com>
…tion (#271) Expose Skybox on the public API and add related methodssetLayerMask/getLayerMask, getIntensity, getTexture. Also adds showSun/intensity args during creation. ThermionViewer.loadSkybox now returns Future<Skybox>.
- ThermionFlutterPluginInitializer -> ThermionTextureBootstrap, moved into the widgets layer next to ViewerWidget; the name now says what it does (deferred texture handshake) instead of implying a scope. - The plugin no longer constructs widgets: buildInitializationScope is replaced by createContextBootstrap/destroyContextBootstrap, which default to null/no-op for platforms without the Linux OpenGL prerequisite. - The injected allocator pair stays a unit: with an injected create hook, destruction falls back to the descriptor, never the plugin. No behavior change; sequencing and dispose-races are covered by texture_bootstrap_test and lifecycle_test. Co-Authored-By: Claude <noreply@anthropic.com>
🤖 Generated with GitHub Actions
The branch was validated on the self-hosted X11/Wayland runner; keep the workflow dispatch-only for future manual runs. Co-Authored-By: Claude <noreply@anthropic.com>
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.
On Linux+EGL, Flutter only exposes the real raster EGLDisplay/EGLContext while
FlTextureGL.populateruns, so desktop EGL initialization and texture operations cannot safely run on the Flutter GTK platform or raster threads.The fix:
populate.This removes the GDK-context fallback but does not change the existing GBM/DMA-BUF texture transport.
We also add a smoke test on both X11 and a headless Weston GL compositor with
GDK_BACKEND=waylandand noDISPLAY, preventing XWayland fallback. This must run a self-hosted runner with a real GPU with read/write access to/dev/dri/renderD128.