suspect-devices/circuitpython/shared-module/displayio, branch 6.1.xCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.1.x2020-12-28T14:34:00+00:00update common_hal_reset_pin()2020-12-28T14:34:00+00:00microDev70126934+microDev1@users.noreply.github.com2020-12-28T14:34:00+00:00urn:sha1:dc332baa87bf1fa3d777ffe31c7dc29b24a6a142OnDiskBitmap: Correct handling of "0 color palette" images2020-12-17T16:54:37+00:00Jeff Eplerjepler@gmail.com2020-12-17T16:54:37+00:00urn:sha1:f224ed18488b1e92b6d13b09b696769a2ac380ce
Microsoft documentation says:
> If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the bitmap has a color table immediatelly following the BITMAPINFOHEADER structure. The color table consists of an array of RGBQUAD values. The size of the array is given by the biClrUsed member. If biClrUsed is zero, the array contains the maximum number of colors for the given bitdepth; that is, 2^biBitCount colors.
Formerly, we treated 0 colors as "no image palette" during construction,
but then during common_hal_displayio_ondiskbitmap_get_pixel indexed into
the palette anyway. This could have unpredictable results. On a pygamer,
it gave an image that was blue and black. On magtag, it gave a crash.
displayio: ColorConverter: fix logic errors about transparent pixels2020-12-16T19:48:27+00:00Jeff Eplerjepler@gmail.com2020-12-16T19:48:07+00:00urn:sha1:28bd29eb42d61d0a7116b6c4295e166fcfbe7145
The transparent_color field was never initialized. I _think_ this means
its value was always set to 0, or the blackest of blacks. Instead,
initialize it to the sentinel value, newly given the name
NO_TRANSPARENT_COLOR.
This exposed a second problem: The test for whether there was an existing
transparent color was wrong (backwards). I am guessing that this was not
found due to the first bug; since the converter had a transparent color,
the correct test would have led to always getting the error "Only one
color can be transparent at a time".
Closes #3723
Merge pull request #3718 from jepler/epd-rotation2020-11-23T23:04:26+00:00Scott Shawcroftscott@adafruit.com2020-11-23T23:04:26+00:00urn:sha1:491e3147994cfc92105b0b77b601d7a26734805b
EPaperDisplay: add rotation propertyFix Palette grayscale for EInk.2020-11-19T00:32:07+00:00Scott Shawcroftscott@tannewt.org2020-11-19T00:28:21+00:00urn:sha1:2463a6d6ac3fb53fa471c77bc585c8ef350d2b96
It needs to do the bitmasking that was only added to ColorConverter
in #3611
EPaperDisplay: add rotation property2020-11-19T00:06:31+00:00Jeff Eplerjepler@gmail.com2020-11-19T00:06:31+00:00urn:sha1:f61f8f999b5eeb8a545f5cea13b30ac5b3aeb04a
untested, because I don't want to mess my magtag demo up :) but it builds
Add .busy property to EPaperDisplay2020-11-14T02:57:52+00:00Scott Shawcroftscott@tannewt.org2020-11-12T00:53:45+00:00urn:sha1:78ccac930fbcb3dddd3a1a79809a2ec371d34c6aAdd board.DISPLAY to MagTag. Fix luma computation2020-11-14T02:57:52+00:00Scott Shawcroftscott@tannewt.org2020-11-11T02:02:16+00:00urn:sha1:8d4296f96430795936a22769da35732e5342b25c
* Initialize the EPaper display on the MagTag at start.
* Tweak the display send to take a const buffer.
* Correct Luma math
* Multiply the blue component, not add.
* Add all of the components together before dividing. This
reduces the impact of truncated division.
use full_change instead of moved2020-11-10T00:14:31+00:00foamyguyfoamyguy@gmail.com2020-11-10T00:14:31+00:00urn:sha1:46c9b28dd880d4e2e2764ab67f64356b175f5f98set moved true when unhiding tilegrid2020-11-09T01:28:46+00:00foamyguyfoamyguy@gmail.com2020-11-09T01:28:46+00:00urn:sha1:9adb77a2d0179f89c7402451f6b25be74629ffbd