|
1 | 1 | Overview |
2 | 2 | == |
3 | | -As the popularity of the library [minifb](https://crates.io/crates/minifb) shows, it is useful to put a 2D buffer/image |
4 | | -on a window in a platform-independent way. Minifb's approach to doing window management itself, however, is problematic |
| 3 | + |
| 4 | +Enables software rendering via drawing an image straight to a window. |
| 5 | + |
| 6 | +Softbuffer integrates with the [`raw-window-handle`](https://crates.io/crates/raw-window-handle) crate |
| 7 | +to allow writing pixels to a window in a cross-platform way while using the very high quality dedicated window management |
| 8 | +libraries that are available in the Rust ecosystem. |
| 9 | + |
| 10 | +Alternatives |
| 11 | +== |
| 12 | + |
| 13 | +[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 |
5 | 14 | code duplication. We already have very high quality libraries for this in the Rust ecosystem |
6 | 15 | (such as [winit](https://crates.io/crates/winit)), and minifb's implementation of window management is not ideal. For |
7 | 16 | example, it occasionally segfaults on some platforms and is missing key features such as the ability to set a window |
8 | 17 | icon. While it would be possible to add these features to minifb, it makes more sense to instead use the standard |
9 | 18 | window handling systems. |
10 | 19 |
|
11 | | -Softbuffer integrates with the [raw-window-handle](https://crates.io/crates/raw-window-handle) crate |
12 | | -to allow writing to a window in a cross-platform way while using the very high quality dedicated window management |
13 | | -libraries that are available in the Rust ecosystem. |
14 | | - |
15 | 20 | What about [pixels](https://crates.io/crates/pixels)? Pixels accomplishes a very similar goal to Softbuffer, |
16 | 21 | however there are two key differences. Pixels provides some capacity for GPU-accelerated post-processing of what is |
17 | 22 | displayed, while Softbuffer does not. Due to not having this post-processing, Softbuffer does not rely on the GPU or |
18 | 23 | hardware accelerated graphics stack in any way, and is thus more portable to installations that do not have access to |
19 | 24 | hardware acceleration (e.g. VMs, older computers, computers with misconfigured drivers). Softbuffer should be used over |
20 | 25 | pixels when its GPU-accelerated post-processing effects are not needed. |
21 | 26 |
|
22 | | - |
23 | 27 | License & Credits |
24 | 28 | == |
25 | 29 |
|
|
0 commit comments