This adds a fallback using `shm_open`/`shm_unlink` for platforms where
`memfd_create` doesn't exist. This seems to be how this is normally
handled, though it's a bit ugly.
This also builds the wayland/x11 code for NetBSD/OpenBSD/DragonFlyBSD.
Add CI builds for FreeBSD and NetBSD. We would need some kind of
virtualisation though to actually run tests on such targets.
I've tested the `shm_open` logic on Linux, but haven't run it on any
BSDs.
This may be redundant since the function is generic and generic
functions are, in the current Rust compiler, always inlinable, but it
follows the general recommended practice of making trivial accessor
functions inlinable.
As documented in the new safety comment, providing `&mut` access to an
inner component about which there are consistency invariants is unsafe,
because `&mut` is sufficient for a caller to completely replace the
value (using assignment or `std::mem::swap()`).
Luckily, when `softbuffer` is used with `winit`, no `&mut` access is
needed. However, other windowing libraries such as `glfw` and `sdl2` do
have `&mut` methods, so this method can't simply be removed.
This is a breaking change since it makes a previously safe function
unsafe, and should not be published without a major version bump
(i.e. to `0.2.0` or higher).
This will allow code which works with windows generically (such as an
event loop which can work with `softbuffer` or another graphics library)
to be able to access the underlying window without knowing about
`softbuffer` in particular.
A limitation of this implementation is that it can't coexist with anything which creates a canvas context other than `CanvasRenderingContext2D`, since only one context can exist per canvas.
