Skip to content

Don't document zero-initializing#346

Open
madsmtm wants to merge 2 commits intomasterfrom
madsmtm/buffer-no-zero-init
Open

Don't document zero-initializing#346
madsmtm wants to merge 2 commits intomasterfrom
madsmtm/buffer-no-zero-init

Conversation

@madsmtm
Copy link
Member

@madsmtm madsmtm commented Mar 16, 2026

That the buffer is zeroed when age == 0 is not guaranteed, e.g. on many platforms (Wayland, X11, Web), when we resize the buffer, we don't also clear it.

We could technically guarantee something like "if the buffer's underlying data could not be reused, the buffer is zero-initialized", but that's not really useful to users (at least not unless we expose additional information in Buffer::age).

This might also make it easier to use zero-copying on Android (might be able to avoid having to clear the buffer if we can prove that the MaybeUninit is actually initialized), see discussion in #331 (comment).

To help a bit with catching mistakes like this in the future / documenting the state of affairs in the code, I've added a private Pixel::INIT which most backends initialize their buffers with.

madsmtm added 2 commits March 16, 2026 02:06
That the buffer is zeroed when `age == 0` is not guaranteed, e.g. on
many platforms (Wayland, X11, Web), when we resize the buffer, we don't
also clear it.

We could technically guarantee something like "if the buffer's
underlying data could not be reused, the buffer is zero-initialized",
but that's not really useful to users (at least not unless we expose
additional information in `Buffer::age`).

This might also make it easier to use zero-copying on Android (might be
able to avoid having to clear the buffer).
To help make it clear that the buffer isn't zero-initialize / catch
mistakes where the user was relying on it.

For example, drawing like this is incorrect:
```
// Fill with blue.
for (_, _, pixel) in buffer.pixels_iter() {
    pixel.b = 0xff;
    pixel.a = 0xff;
}
```
@madsmtm madsmtm added the documentation Improvements or additions to documentation label Mar 16, 2026
@madsmtm madsmtm requested a review from MarijnS95 as a code owner March 16, 2026 01:21
@madsmtm madsmtm added the enhancement New feature or request label Mar 16, 2026
@madsmtm
Copy link
Member Author

madsmtm commented Mar 16, 2026

Note that zero-initializing might have been useful in the past, because it corresponded to black, but it isn't really useful after #321, after that we panic when cfg!(debug_assertions) if the user doesn't set a pixel with an opaque alpha value (and zero-initialized data has transparent alpha values).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation enhancement New feature or request

Development

Successfully merging this pull request may close these issues.

2 participants