Skip to content

Commit f320021

Browse files
committed
Rework documentation for GraphicsContext::set_buffer
This includes a more clear description of the pixel format expected.
1 parent 1381217 commit f320021

File tree

1 file changed

+38
-16
lines changed

1 file changed

+38
-16
lines changed

src/lib.rs

Lines changed: 38 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -236,28 +236,48 @@ impl Surface {
236236
}
237237

238238
/// Shows the given buffer with the given width and height on the window corresponding to this
239-
/// graphics context. Panics if buffer.len() ≠ width*height. If the size of the buffer does
240-
/// not match the size of the window, the buffer is drawn in the upper-left corner of the window.
239+
/// surface.
240+
///
241241
/// It is recommended in most production use cases to have the buffer fill the entire window.
242-
/// Use your windowing library to find the size of the window.
242+
/// Use your windowing library to determine the size of the window.
243+
///
244+
/// # Panics
245+
///
246+
/// - If `buffer.len() ≠ width * height`
243247
///
244-
/// The format of the buffer is as follows. There is one u32 in the buffer for each pixel in
245-
/// the area to draw. The first entry is the upper-left most pixel. The second is one to the right
246-
/// etc. (Row-major top to bottom left to right one u32 per pixel). Within each u32 the highest
247-
/// order 8 bits are to be set to 0. The next highest order 8 bits are the red channel, then the
248-
/// green channel, and then the blue channel in the lowest-order 8 bits. See the examples for
249-
/// one way to build this format using bitwise operations.
248+
/// # Pixel format
250249
///
251-
/// --------
250+
/// The buffer layout is in a row-major layout. The buffer is drawn in the upper-left corner of
251+
/// the window. The x axis grows to the right and the y axis grows downwards.
252252
///
253-
/// Pixel format (u32):
253+
/// Each pixel is represented in memory as a [`u32`]. Starting with the most significant byte (MSB)
254+
/// going to the least significant byte (LSB), the byte is ignored but best set to `0`. Then there is
255+
/// a byte for the red, green and blue channel.
254256
///
255-
/// 00000000RRRRRRRRGGGGGGGGBBBBBBBB
257+
/// ```text
258+
/// XXXXXXXXRRRRRRRRGGGGGGGGBBBBBBBB
259+
/// ^ ^
260+
/// MSB LSB
261+
/// ```
256262
///
257-
/// 0: Bit is 0
258-
/// R: Red channel
259-
/// G: Green channel
260-
/// B: Blue channel
263+
/// | Bit | Channel |
264+
/// |------|---------------------|
265+
/// | X | Ignored[^x-channel] |
266+
/// | R | Red channel |
267+
/// | G | Green channel |
268+
/// | B | Blue channel |
269+
///
270+
/// The function shown below may be used to create a color from a 24-bit RGB color using bitwise\
271+
/// operations:
272+
///
273+
/// ```
274+
/// fn pixel(red: u8, green: u8, blue: u8) -> u32 {
275+
/// let color = blue as u32
276+
/// | ((green as u32) << 8)
277+
/// | ((red as u32) << 16);
278+
/// color
279+
/// }
280+
/// ```
261281
///
262282
/// # Platform dependent behavior
263283
///
@@ -272,6 +292,8 @@ impl Surface {
272292
///
273293
/// If the caller wishes to synchronize other surface/window changes, such requests must be sent to the
274294
/// Wayland compositor before calling this function.
295+
///
296+
/// [^x-channel]: On some backends setting these bits to anything other than `0` may cause weird behavior.
275297
#[inline]
276298
pub fn set_buffer(&mut self, buffer: &[u32], width: u16, height: u16) {
277299
if (width as usize) * (height as usize) != buffer.len() {

0 commit comments

Comments
 (0)