* Linux: only disable WebKit compositing for WebKitGTK older than 2.42
The default Wayland path set WEBKIT_DISABLE_COMPOSITING_MODE=1 whenever the
session had both DISPLAY and WAYLAND_DISPLAY, i.e. any Wayland session with
XWayland. That forces WebKitGTK accelerated compositing off and also disables
threaded scrolling, so the Device tab web view (Mainsail/Fluidd) lagged unless
the app was launched with GDK_BACKEND=x11, the only path that skipped the
variable. Disabling compositing also turns off threaded scrolling.
The XWayland compositing bug the fallback worked around is fixed in WebKitGTK
>= 2.42, so apply it only for older WebKit. WebView::NeedsCompositingWorkaround()
reads the runtime WebKitGTK version; the X11 opt-in path is unchanged.
Behavior is unchanged on WebKit < 2.42, on pure X11, and on native Wayland
without XWayland. The wxWidgets skill reference is updated to match.
* Linux: use WebKit's shared-memory transport for the NVIDIA DMABUF renderer
The Device tab web view is slow on NVIDIA proprietary drivers even with
accelerated compositing left on: since the DMABUF renderer became the
default in WebKitGTK 2.42, the driver cannot back it, and web views fall
back to a slow path. Gating the old WEBKIT_DISABLE_COMPOSITING_MODE
fallback on WebKit < 2.42 is the wrong axis, because the failure is
version-independent from 2.42 on.
Force the shared-memory transport with WEBKIT_DMABUF_RENDERER_FORCE_SHM=1.
That keeps compositing and threaded scrolling and skips only the hardware
path. Also set WEBKIT_FORCE_DMABUF_RENDERER=1, which clears the isNVIDIA()
early return that Debian/Ubuntu/openSUSE patch into
rendererBufferTransportMode() and which otherwise returns before the
FORCE_SHM check is reached.
Both are set before the X11-vs-Wayland split so the workaround also covers
XWayland, and only when WebKitGTK is new enough to honour FORCE_SHM
(>= 2.44, WebView::SupportsForceSharedMemory()).
The AppImage launcher exported the superseded
WEBKIT_DISABLE_DMABUF_RENDERER=1, which is read first, leaves the transport
set empty and so disables compositing outright; replace it with the same
pair. The wxWidgets skill reference is updated to match.
* Linux: drop the AppImage WebKit DMABUF exports; correct the skill notes
The launcher cannot gate on the runtime WebKitGTK version, so exporting
WEBKIT_DMABUF_RENDERER_FORCE_SHM/WEBKIT_FORCE_DMABUF_RENDERER there would
clear a distro isNVIDIA() guard on hosts older than 2.44, where FORCE_SHM
is ignored, re-exposing the broken hardware path. The binary already sets
both with the correct gate, so remove them and say who owns the workaround.
Also correct two claims in the skill reference. An empty transport set only
means "no accelerated compositing" from 2.44 on; 2.42/2.43 still fall back
to the Wayland/X11 renderers, removed in the same release that added
FORCE_SHM. And threaded scrolling is off by default in 2.44/2.45 (on from
2.46), so FORCE_SHM keeps compositing rather than scrolling. Document the
module-level detection cost and the WEBKIT_DMABUF_RENDERER_FORCE_SHM=0
opt-out.
* Flatpak: force WebKit's shared-memory transport instead of disabling DMABUF
The entrypoint exported WEBKIT_DISABLE_DMABUF_RENDERER=1 for NVIDIA. WebKit
reads that variable first and leaves the transport set empty, which turns
accelerated compositing off, so the Device tab still lagged for NVIDIA
Flatpak users, and the binary could not override it because its setenv is
non-replacing.
The runtime's WebKitGTK is vanilla, so there is no distro isNVIDIA() guard
to clear and WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 alone is the right switch:
compositing stays on and only the hardware DMABUF path is skipped.
* Flatpak: drop the WebKit NVIDIA export; the binary owns the workaround
/proc/driver/nvidia/version is readable inside the Flatpak sandbox, so the
binary's NVIDIA branch already sets WEBKIT_DMABUF_RENDERER_FORCE_SHM with
the correct runtime gate and the entrypoint's own export is redundant.
Verified with:
flatpak run --command=cat com.orcaslicer.OrcaSlicer /proc/driver/nvidia/version
which prints the NVRM version (driver 615.71.09) from inside the sandbox.
* Linux: say what the XWayland compositing gate actually tests
DISPLAY and WAYLAND_DISPLAY are both set in a native Wayland session as
well, because GNOME and KDE run Xwayland as part of the session and export
DISPLAY for it whether or not this process is an X client. The pair means
XWayland is available in the session, not that GTK picked X11 for this
process, so "(an XWayland session)" reads as more than the condition
establishes.
Say what the pair means, and name the case the fallback actually covers:
the X11 backend inside a Wayland session, which is what the forced
GDK_BACKEND=x11 above produces in a build without EGL.
Comment only; behaviour is unchanged.
* Linux: apply the XWayland compositing fallback only where GTK picks X11
The default path set WEBKIT_DISABLE_COMPOSITING_MODE whenever DISPLAY and
WAYLAND_DISPLAY were both set, but a native Wayland app inherits both, so a
build with EGL disabled accelerated compositing — and with it threaded
scrolling — while running on Wayland, where the XWayland bug does not apply.
The only default-path case that really runs through XWayland is the forced
GDK_BACKEND=x11 used when wx lacks EGL, so set the variable there. The
backend cannot be re-checked later: that branch exports GDK_BACKEND itself,
so the force and a user's GDK_BACKEND=x11 opt-in, which deliberately keeps
compositing, would be indistinguishable.
Behaviour is unchanged for WebKitGTK >= 2.42, where the gate already skipped
the variable, and for builds without EGL. A build with EGL on WebKitGTK <
2.42 in a Wayland session no longer loses compositing and threaded scrolling.
The wxWidgets skill reference is updated to match.
---------
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
Profiling build_linux_image.sh: 96 s, of which 51 s in the dependency audit.
appimage_is_elf_file() ran file(1) and grep per candidate. An AppDir holds ~9.6k
of them, 4.8k being the bundled Python runtime, none of them ELF: ~19k processes
for 14 s. Read the four-byte magic instead; checked against the old result on
4000 files, no disagreement.
The dependency walk popped its queue with "${queue[@]:1}", which rebuilds the
whole array each time. At ~4.8k entries that was 22 s of copying. Use a read
index.
96 s -> 12.7 s. The audit still passes.
The AppImage dependency closure resolves each bundled ELF's DT_NEEDED
entries with plain ldd, which cannot resolve the deps-built FFmpeg stack
(libavcodec/libavutil/libswscale) once it is copied into the bundle:
those libs are not installed in any standard loader path and carry no
RUNPATH of their own, so ldd reports the siblings as missing and the
build aborts. Extend the loader path with the bundle directory plus the
source directories of already-bundled files (mirroring
scripts/check_appimage_libs.sh), and key the dedup set on the bundled
file path instead of the source path so dependencies resolved from the
bundle directory are not copied onto themselves.
Co-Authored-By: Claude <noreply@anthropic.com>
- add a new mode to build in docker
- Improve AppImage
1. fix libbz2 soname differeence issue on appimage
2. Downgrade to 22.04 for better compatibility
3. improve appimage overall
* Actually build tests on Linux and allow RelWithDebInfo
They weren't being built.
Also cleaned up --config flags which enables RelWithDebInfo on Linux,
now that Ninja Multi-Config is used, it's quite trivial.
* Remove obsolete Slic3r Perl tests
The directory doesn't exist, they're already gone.
* Add GH job for running unit tests
* Move unit test execution to script and upload test results
* Don't run scheduled builds on forks
* Only deploy from SoftFever/OrcaSlicer
Will stop failures on forks
* Use artifact instead of cache
* Tweak archive and checkout paths
Keep getting error:
```
/home/runner/work/_temp/902d0a0a-6d23-4fe0-a643-8b5cc4efd25b.sh: line 1: scripts/run_unit_tests.sh: Permission denied
```
That seems to be because I didn't use actions/checkout, the working
directory is never setup correctly? So using checkout to get scripts
directory. Unsure if archive will preserve the `build/tests/` prefix;
will find out soon.
* Use tar to package directory and write results to correct directory
Tar preserves filenames and directory structure
* Use tar -xvf not -xzf
Muscle memory failed me
* Add testing wiki page
* Save test logs on failure and choose correct directory for junit
* Consolidate apt install steps, use for unit tests too, disable non-Linux builds
Temporarily disable non-Linux builds to save time while developing
this.
Cache the apt packages to save some time searching apt and downloading
them again (though I realize this is also downloading, but hopefully
by something closer and faster).
Remove all the redundant packages listed in the workflow and debian
distribution lists.
* Remove apt install steps from workflow
`./build-linux.sh -u` is supposed to install all needed packages, so
it should build without needing anything besides that. If I'm wrong
this commit will be dropped.
* Need composite action checked out locally
* Re-enable non-Linux builds now that it's working
* Skip a deploy and a notarize in forks
They only succeed in the main repo.
* Fix multi-build for non-Release builds: share CONFIG
* Correct build errors in unit tests
Indeterminate method signatures resolved. Updated script to build all
the tests.
* Fix -g vs -e for RelWithDebInfo
* Change CONFIG->BUILD_CONFIG
Missed one in prior commits
* Reduce wasteful redundant build artifact copies
1. Don't copy the artifacts and leave them; make a hard link first;
only make a copy only while creating AppImage.
2. Don't tar up the `package` directory; nothing uses this tar AFAICT
* Fix directory name
* Change jigsaw auth test URLs to httpbin.org
No idea why the basic auth doesn't work, but it doesn't work for
`curl` CLI either. This does.
* Remove force-build
It got reverted at
https://github.com/SoftFever/OrcaSlicer/commit/e3f049829bff3ac4de9fd271768948efc150e4c3
for unknown reasons.
* Add timeout for unit tests in GitHub Actions workflow (#11146)
---------
Co-authored-by: SoftFever <softfeverever@gmail.com>
Move many third-party components' source codes from the src folder to a new folder called deps_src. The goal is to make the code structure clearer and easier to navigate.
