Change:
, compat28 ? false , compat30 ? true , unicode ? true <ins> , withEGL ? true </ins> , withGtk2 ? (!stdenv.isDarwin) , withMesa ? lib.elem stdenv.hostPlatform.system lib.platforms.mesaPlatforms , withWebKit ? stdenv.isDarwin

Discussion:
Try to run super-slicer from nixos-unstable, on Wayland. The 3D view doesn't render at all, and the console logs are full of . I'm on Wayland, haven't checked if this repros in X11 or not. Steps to reproduce the behavior: On Wayland: ! (the gray window on the RHS should be a rendered 3D canvas with a 3D printer build plate in it) This appears to have been caused by the wxWidgets upgrade to 3.1.5. 3.1.5 apparently enabled EGL support by default, and this causes some incompatibility in the bowels of SuperSlicer/wxWidgets/GLEW somewhere. There seem to be ~3 options to fix, with varying degrees of grossness: Option 1: FreeBSD worked around this in prusa-slicer by hacking out the : . Ew! Option 2: suggests rebuilding wxWidgets with to revert to 3.1.4 behavior. I've confirmed that rebuilding wxWidgets like this in nixpkgs fixes superslicer's rendering. Note if we do this, Kicad will need a partial revert of , where it enabled EGL in kicad's build to function with the new wxWidgets. I guess the question here is whether we suspect that wxWidgets+EGL is more widely broken than just the slic3r family of programs? Option 3: Prusa Slicer in nixpkgs is already being built with a forked 3.1.4 wxWidgets. SuperSlicer is explicitly overriding that back to stock 3.1.5, which is why Prusa Slicer is still working fine in unstable. I've verified that changing superslicer to use prusa3d's wxWidgets fork also fixes rendering. Most likely any 3.1.4 wxWidgets will work, but prusa3d's version is handy because it's already in nixpkgs. This is just delaying the headaches though: at some point prusaslicer will upgrade its wxWidgets and either this will break again, or prusaslicer will be fine but then superslicer will be broken until it finishes its rebase onto newer prusaslicer (which usually takes a few months iirc).

(wxWidgets maintainer), (prusa-slicer/superslicer maintainers), (kicad maintainers) Please run and paste the result.
side note: wouldn't happen to know what change enabled EGL by default? i'm building super-slicer with wxwidgets 3.2.1 to see if that changes anything
with 3.2.1 it just segfaults
The change is just an upstream change: wxWidgets 3.1.5 turned on EGL support by default for wxGLCanvas. Previously it was a build flag but off by default. Source: . Given that Kicad seems to work with 3.1.5+EGL, I'm guessing the slic3r-derivative codebases are doing something wrong when EGL is involved. I guess that sort of makes sense since Kicad needed some ifdefs to make EGL work...
I think option 2, but with an option to the wxwidgets derivation for enabling/disabling EGL support, and overriding wxwidgets in all- for only those packages that have problems. Or if we want to be more conservative for now, only enabling it for packages that have confirmed support like kicad. Or we could add a package variant to make the intention clearer. On the other hand this is likely a temporary problem. I'd still prefer this.
Sounds reasonable to me. As you say this should be a temporary problem and I couldn't find anything but slic3r derivatives reporting this issue, so I'll prepare a PR that parameterizes the wxwidgets derivation and fixes up super-slicer in all-
Prusa folks did some digging and filed upstream, which looks like the bug superslicer hits with EGL. So, the option in should indeed be temporary until an upcoming wxwidgets relase :crossed_fingers: