From 104ea4205dd03c99de55237816ba7b7b1c068211 Mon Sep 17 00:00:00 2001 From: John Nunley Date: Sat, 7 Sep 2024 10:43:45 -0700 Subject: [PATCH] docs: Clean up README.md a little Signed-off-by: John Nunley --- README.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 599df21..be7084b 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,22 @@ Overview == -As the popularity of the library [minifb](https://crates.io/crates/minifb) shows, it is useful to put a 2D buffer/image -on a window in a platform-independent way. Minifb's approach to doing window management itself, however, is problematic + +Enables software rendering via drawing an image straight to a window. + +Softbuffer integrates with the [`raw-window-handle`](https://crates.io/crates/raw-window-handle) crate +to allow writing pixels to a window in a cross-platform way while using the very high quality dedicated window management +libraries that are available in the Rust ecosystem. + +Alternatives +== + +[minifb](https://crates.io/crates/minifb) also allows putting a 2D buffer/image on a window in a platform-independent way. Minifb's approach to doing window management itself, however, is problematic code duplication. We already have very high quality libraries for this in the Rust ecosystem (such as [winit](https://crates.io/crates/winit)), and minifb's implementation of window management is not ideal. For example, it occasionally segfaults on some platforms and is missing key features such as the ability to set a window icon. While it would be possible to add these features to minifb, it makes more sense to instead use the standard window handling systems. -Softbuffer integrates with the [raw-window-handle](https://crates.io/crates/raw-window-handle) crate -to allow writing to a window in a cross-platform way while using the very high quality dedicated window management -libraries that are available in the Rust ecosystem. - What about [pixels](https://crates.io/crates/pixels)? Pixels accomplishes a very similar goal to Softbuffer, however there are two key differences. Pixels provides some capacity for GPU-accelerated post-processing of what is displayed, while Softbuffer does not. Due to not having this post-processing, Softbuffer does not rely on the GPU or @@ -19,7 +24,6 @@ hardware accelerated graphics stack in any way, and is thus more portable to ins hardware acceleration (e.g. VMs, older computers, computers with misconfigured drivers). Softbuffer should be used over pixels when its GPU-accelerated post-processing effects are not needed. - License & Credits ==