I believe this should be possible wherever `memfd_create` is available.
Sealing isn't required, but Wayland doesn't allow a client to shrink an
shm pool, so there's no reason we should shrink the file. And if we mmap
the file, this prevents a `SIGBUS` if the compositor (incorrectly)
shrunk it.
So we might as well do this.
This commit fixes a bug in the Core Graphics backend that causes a new
buffer not be shown immediately but instead use a quarter second fade
transition. This happens because the CALayer has a default action
associated with a change in the layer contents.
The problem was mitigated by wrapping the contents change in a
transaction and disabling all actions for the duration of this
transaction.
This commit adds a new example that shows a XOR pattern. A rectangle can
be superimposed on the background by pressing the space bar.
This example was created to demonstrate a bug in the Core Graphics
backend that causes the buffer to fade when calling set_buffer, instead
of applying it immediately.
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.
https://github.com/rust-windowing/softbuffer/issues/41
If `set_buffer` can just be called in a loop without waiting for buffers
to be released or a frame callback, but can also be called in other
ways, I don't know if there's a better solution than blocking.
Should fix https://github.com/rust-windowing/softbuffer/issues/48. The
animation example could probably be implemented better, but this is at
least better.
I guess it should be documented that `set_buffer` may block? I don't
know how this compares to other backends.
