Conversation
Interpreting parts of a Mask as a "SubPixmapMut" was confusing because SubPixmapMut (typically) has 4-byte pixels, while Mask uses 1-byte pixels. The new GenericPixmapMut struct should also make it easier to handle non-u8888 pixel formats in the future.
mstoeckl
changed the title
This only implements a single pixel type (the current RgbaU8), but introduces some stride alignment checks and match expressions that should be useful when implementing this in the future. Unfortunately the direct pixel access methods like pixels_mut() had to be removed for the Pixmap to remain general over PixelType, and handle strides which are not a multiple of the pixel byte size. While it may be possible to add simple abstractions for efficient pixel and row access, the logic for users to do this themselves with data_mut() and bytemuck is not very complex. The (currently inactive) constraints on pixel type alignment will likely be needed to efficiently (in both time and code size) operate on pixel types with higher bit depth. This eliminates the internal SubPixmapMut type, and makes public the power to construct lightweight views for rectangles of PixmapMut and PixmapRef through their ::subpixmap methods.
This will be needed to allocate memory for future PixelTypes which have alignment constraints.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This eliminates the internal SubPixmapMut type, adds stride parameters to the Pixmap* types, and adds a PixelType parameter that can be used in the future to support new pixel types (like Rgba16F, or RgbaU16). This modifies and adds new methods for these parameters (and makes a usable form of ::subpixmap() public), but also removes methods like PixmapMut::pixels_mut() which embedded assumptions that no longer apply.
I've made Pixmap hold a dynamic PixelType instead of making the struct generic, because 1) the overhead of looking up the pixel type is negligible, and it's never done in hot code 2) this should help keep code size down 3) Skia's skPixmap does the same 4) my experience using the
imagecrate is that encoding pixel types in the type system by default can make using the library awkward, especially when more generics get involved.)