Skip to content

Conversation

@corranwebster
Copy link

Summary

Experiments with minimal alpha blending. Particularly care about code-size on different platforms.

Testing

Nothing yet.

Trade-offs and Alternatives

This can do everything at the cost of having multiple buffers.

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.
This is mainly adding tests for code branches not currently tested:
- exceptions caused by bad masks in blit()
- fast exit from certain functons when alpha is 0
- all lines are horizontal in polygon fill (nothing to draw)

It also removes a small piece of dead code in polygon outline rendering..

Signed-off-by: Corran Webster <[email protected]>
This adds a handful of tests to ensure that off-screen polygons don't draw
anything.

Signed-off-by: Corran Webster <[email protected]>
Rather than having separate big-endian and little-endian modes at the C level
use native and non-native, allowing RGB565 to be the same as one of RGB565_LE
or RGB565_BE as appropriate.

Signed-off-by: Corran Webster <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants