This function is useful for testing the window contents in certain cases. In addition,
this means that we can now have reliable tests for softbuffer's actual functionality.
Signed-off-by: John Nunley <jtnunley01@gmail.com>
Co-authored-by: dAxpeDDa <daxpedda@gmail.com>
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.
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.
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.
