This is based on the API that will be used for no-copy presentation. But
wraps it in `set_buffer`.
This also fixes the Wayland buffer code to set `self.width` and
`self.height` on resize, and set the length of the shared memory file
when the buffer is created.
Co-authored-by: jtnunley <jtnunley01@gmail.com>
A `Context` is created with a display handle, and a `Surface` is created
with a `&Context` and a window handle. Thus multiple windows can be
created from the same context without duplicating anything that can be
shared. This API is broadly similar to `wgpu` or `glutin`.
On Wayland, the `Context` contains the `EventQueue`, which is shared
between windows, and the `WlShm` global. On X11, `Context::new` checks
for the availability of XShm, and contains a bool representing that as
well as the `XCBConnection`. The shared context data is stored within
the window in an `Arc`.
On other platforms, the display isn't used and `Context` is empty. This
does however test that the display handle has the right type on those
platforms and fail otherwise. Previously the code didn't test that.
Closes https://github.com/rust-windowing/softbuffer/issues/37.
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 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.
Currently the size of the buffer on macOS is interpreted in logical pixels, which
is inconsistent with the other platforms. Instead,
we should apply the same scale factor that applies to regular rendering.
Also updates `winit` example to redraw on resize, which seems to be
necessary.
With this resizing seems to be entirely smooth, without visual
corruption from it overwriting the buffer the server is displaying.
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.
