RGB565 byteswapped format #1
Open
Conversation
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
This is required for identifying which bits are in which channels for alpha blending. It also has some utility when working with display devices where the display memory is opposite endianness from the microcontroller, as it permits more straightforward translation from colors to bytes.
Add tests for byteswapped RGB565 format.
Without this, we don't know the bits per pixel.
Re-use the rgb565_fill_rect() function to avoid repeated code.
This keeps the internal C code more-or-less unchanged, but exposes the byte-order as "RGB565_LE" and "RGB565_BE" for little and big endian versions. Updates docs and tests and, as a bonus, turns on RGB565 testing for big-endian native systems.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
This adds a byte-swapped version of the RGB565 format to the the framebuf module, so that pixel color values get stored in the opposite order to the native endianness (ie. if you do
buf.pixel(x, y, 0xff00)it gets stored as0x00ff). This is useful for working with devices which have opposite endianness to the primary device (eg. many 16-bit color displays). This removes the need for a lot of manual byte-swapping when creating color values.Testing
Added tests for the new format which follow the existing 16-bit tests.
Trade-offs and Alternatives
This has a very small increase in code size. The other alternative would be to have explicit big/little endian formats, but that would potentially break existing code, or would mean having to add 2 new formats (ie.
RGB565is native endianness,RGB565_BEis big-endian, andRGB565_LEis little-endian) one of which is identical to RGB565.