this happens to make the occasional FS dither artifact disappear.
I guess `a * b >> 8` and `(a * b) / 256` are not identical. I'm not
sure if it was just the parens or not, but write the clearer code and
rely on the compiler to substitute an appropriate shift if possible.
This blends two "565"-format bitmaps, including byteswapped ones. All
the bitmaps have to have the same memory format.
The routine takes about 63ms on a Kaluga when operating on 320x240 bitmaps.
Of course, displaying the bitmap also takes time.
There's untested code for the L8 (8-bit greyscale) case. This can be
enabled once gifio is merged.
This is a modest code savings, but more importantly it reduces
boilerplate in bitmap-modifying routines.
Callers need only ensure they call displayio_bitmap_set_dirty_area in
advance of the bitmap modifications they perform.
(note that this assumes that no bitmap operation can enter background
tasks. If an operation COULD enter background tasks, it MUST re-dirty
the area it touches when it exits, simply by a fresh call to
set_dirty_area with the same area as before)
.. simplifying code in the process. For instance, now fill_region
uses area routines to order and constrain its coordinates.
Happily, this change also frees a modest amount of code space.
When reading uncompressed bitmap data directly, readinto can work
much more quickly than a Python-coded loop.
On a Raspberry Pi Pico, I benchmarked a modified version of
adafruit_bitmap_font's pcf reader which uses readinto instead of
the existing code. My test font was a 72-point file created from Arial.
This decreased the time to load all the ASCII glyphs from 4.9 seconds to
just 0.44 seconds.
While this attempts to support many pixel configurations (1/2/4/8/16/24/32
bpp; swapped words and pixels) only the single combination used by
PCF fonts was tested.
