Skip to content

Comments

painter/pixel: validate single-pixel sources for pre-multiplied values#165

Merged
vancluever merged 1 commit intomainfrom
pixel-check-premultiply
Feb 3, 2026
Merged

painter/pixel: validate single-pixel sources for pre-multiplied values#165
vancluever merged 1 commit intomainfrom
pixel-check-premultiply

Conversation

@vancluever
Copy link
Owner

This adds a few thing to enable validation of single-pixel sources with alpha channels:

  • canDemultiply has been added on ARGB and RGBA types, this just ensures that a de-multiply operation will not overflow, validating that the pixel has been pre-multiplied (or effectively pre-multiplied through manual supplying of values, or the pixel just being opaque).

  • Validation through this functionality has been added to painter.fill and painter.stroke, returning PixelSourceNotPreMultiplied if it indeed can't be done.

The combination of these two actions should prevent this footgun in the major paths that it is encountered in when supplying pixel values directly for fill or stroke operations.

This adds a few thing to enable validation of single-pixel sources with
alpha channels:

* canDemultiply has been added on ARGB and RGBA types, this just ensures
  that a de-multiply operation will not overflow, validating that the
  pixel has been pre-multiplied (or effectively pre-multiplied through
  manual supplying of values, or the pixel just being opaque).

* Validation through this functionality has been added to painter.fill
  and painter.stroke, returning PixelSourceNotPreMultiplied if it indeed
  can't be done.

The combination of these two actions should prevent this footgun in the
major paths that it is encountered in when supplying pixel values
directly for fill or stroke operations.
@vancluever vancluever added the enhancement New feature or request label Feb 1, 2026
@vancluever
Copy link
Owner Author

Note: I'm holding off on adding this to the compositor for now, as fill/stroke is the main path for most operations and using the compositor directly generally implies more unsafe operations. However, comments have been added to the compositor in the spots where most people would interface with things (SurfaceCompositor and StrideCompositor).

Note that overflows due to bad pre-multiplied pixel values would only be confined to pixel value operations and would just produce "undefined" output in that the intCast back to pixel memory truncates bits. So likely still "safe" in the sense that we're not dealing with buffer overflows or anything, just garbled output on the screen. Any safety implications due to that are really out of scope for us.

There are some spots where we could add additional checking (SurfaceCompositor would only need to check once, and we could just do some asserts after checking for runtime safety), but this should be good for now and catches the biggest path of confusion for most people.

@vancluever vancluever merged commit d17e2e5 into main Feb 3, 2026
2 checks passed
@vancluever vancluever deleted the pixel-check-premultiply branch February 3, 2026 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant