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.
Previously, `softbuffer` wouldn't successfully build on its own on Windows; the examples only worked because dependencies happened to enable the needed features.
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.
