Skip to content

Commit 57835ec

Browse files
committed
Add "how it works" section to README
1 parent 2c4005d commit 57835ec

1 file changed

Lines changed: 17 additions & 0 deletions

File tree

README.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,23 @@ like [`tiny-skia`](https://docs.rs/tiny-skia/) or [`vello_cpu`](https://docs.rs/
2020

2121
[`raw_window_handle::HasWindowHandle`]: https://docs.rs/raw-window-handle/0.6.2/raw_window_handle/trait.HasWindowHandle.html
2222

23+
## How it works
24+
25+
Most platforms have a compositor of some sort (WindowServer on macOS, Desktop Window Manager on
26+
Windows, the Wayland compositor, etc). This is a separate process that applications communicate
27+
with over IPC, and it is responsible for taking the various surfaces that applications send to it
28+
and mash ("composite") them together in the right way to render the user's desktop on the
29+
connected monitors.
30+
31+
The role of Softbuffer then is to create a shared memory region (i.e. [`Buffer`]) that can be
32+
written to from the CPU, and then handed to the compositor (in [`Buffer::present`]). Softbuffer
33+
keeps a set of buffers around per surface to implement double-buffering (depending on platform
34+
requirements).
35+
36+
Softbuffer strives to present buffers in a zero-copy manner. One interesting wrinkle here is that
37+
the compositor is often GPU-accelerated, so on platforms without a unified memory architecture,
38+
some copying is inherently necessary (though when possible, it is done in hardware using DMA).
39+
2340
## Platform support:
2441

2542
Some, but not all, platforms supported in [raw-window-handle](https://crates.io/crates/raw-window-handle) are supported

0 commit comments

Comments
 (0)