Skip to content

Don't document zero-initializing - #346

Merged
madsmtm merged 2 commits into
masterfrom
madsmtm/buffer-no-zero-init
Mar 18, 2026
Merged

Don't document zero-initializing#346
madsmtm merged 2 commits into
masterfrom
madsmtm/buffer-no-zero-init

Conversation

@madsmtm

Copy link
Copy Markdown
Member

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.

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;
}
```
@madsmtmmadsmtm added the documentation Improvements or additions to documentation label Mar 16, 2026
@madsmtm
madsmtm requested a review from MarijnS95 as a code ownerMarch 16, 2026 01:21
@madsmtmmadsmtm added the enhancement New feature or request label Mar 16, 2026
@madsmtm

Copy link
Copy Markdown
MemberAuthor

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).

@madsmtm
madsmtm merged commit 61e21b5 into masterMar 18, 2026
40 checks passed
@madsmtm
madsmtm deleted the madsmtm/buffer-no-zero-init branch March 18, 2026 14:25
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentationImprovements or additions to documentationenhancementNew feature or request

Development

Successfully merging this pull request may close these issues.

2 participants

@madsmtm@notgull