leyoda/softbuffer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fork to swbuf

Browse source
This commit is contained in:
Jeremy Soller 2022-12-20 07:07:08 -07:00
parent d30d3255c2
commit 939bcc44d8
No known key found for this signature in database
GPG key ID: 87F211AF2BE4C2FE
8 changed files with 241 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

20
README.md
View file

@ -1,5 +1,7 @@
Overview
==
This is a fork of [softbuffer](https://github.com/john01dav/softbuffer) for more active maintenance, as softbuffer now appears to be unmaintained. Currently, it is a drop-in replacement for softbuffer, and many things are the same (including this README).
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
code duplication. We already have very high quality libraries for this in the Rust ecosystem
@ -8,15 +10,15 @@ example, it occasionally segfaults on some platforms and is missing key features
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
swbuf 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,
What about [pixels](https://crates.io/crates/pixels)? Pixels accomplishes a very similar goal to swbuf,
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
hardware accelerated graphics stack in any way, and is thus more portable to installations that do not have access to
hardware acceleration (e.g. VMs, older computers, computers with misconfigured drivers). Softbuffer should be used over
displayed, while swbuf does not. Due to not having this post-processing, swbuf does not rely on the GPU or
hardware accelerated graphics stack in any way, and is thus more portable to installations that do not have access to
hardware acceleration (e.g. VMs, older computers, computers with misconfigured drivers). swbuf should be used over
pixels when its GPU-accelerated post-processing effects are not needed.
@ -28,8 +30,8 @@ from the minifb library to do platform-specific work.
Platform support:
==
Some, but not all, platforms supported in [raw-window-handle](https://crates.io/crates/raw-window-handle) are supported
by Softbuffer. Pull requests are welcome to add new platforms! **Nonetheless, all major desktop platforms that winit uses
Some, but not all, platforms supported in [raw-window-handle](https://crates.io/crates/raw-window-handle) are supported
by swbuf. Pull requests are welcome to add new platforms! **Nonetheless, all major desktop platforms that winit uses
on desktop are supported.**
For now, the priority for new platforms is:
@ -53,7 +55,7 @@ For now, the priority for new platforms is:
Example
==
```no_run
use softbuffer::GraphicsContext;
use swbuf::GraphicsContext;
use winit::event::{Event, WindowEvent};
use winit::event_loop::{ControlFlow, EventLoop};
use winit::window::WindowBuilder;
@ -112,4 +114,4 @@ See git tags for associated commits.
0.1.0
-----
Initial published version with support for Linux (X11 and Wayland), Mac OS (but buggy), and WIndows.
Initial published version with support for Linux (X11 and Wayland), Mac OS (but buggy), and WIndows.