|
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