Division is more expensive than multiplication, and this doesn't seem to
be optimize away, so iterating over `(0..height)` and `(0..width)`
provides better performance.
It's good to have the example show the best way to write code using
softbuffer, and this helps when using examples as a benchmark. This will
also be needed if Softbuffer supports formats where `stride` isn't just
`width * pixel_size`, and needs alignment.
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>
Using the latest `winit` version in examples fixes resizing behavior on
Wayland, so the workaround for that in the `winit` example is also
removed here.
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 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.
