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.
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.
