Request for slice capability for bitmap manipulation

[kmatch98]

This is a request for capability for slice manipulation for bitmaps. This would allow more of the code to be performed "down" at the C-level rather than item-by-item manipulation up at the CircuitPython level.

Use case description: For developing an updated text display capability to reduce memory usage vs. label when using imported BDF files, one way is to create a bitmap buffer to contain the text, rather than a group of tileGrids. To do this, I copy each glyph bitmap into the display bitmap buffer. This is currently implemented in this textMap library. Currently I iterate across the x and y of the small glyph bitmap and copy it into a larger Target bitmap at the Target x,y location.

A superior approach could be a method where I pass a source bitmap with slice notation (if I want to copy only a portion of the source bitmap) and then a Target bitmap and Target x,y location. If this copying can happen more down at the C-level it would likely be faster compared to the element by element copying approach.

Additional background: This issue suggests that direct index manipulation of arrays array[3] can be superior to x,y tuple array[0,3] manipulation of arrays #2688. I updated my textMap library to use direct indexing and got a 20% reduction in time (the test includes rendering plus a lot of other parsing work, so the bitmap writing speed improvement alone was actually improved more than 20%).

[v923z]

You can slice 2D arrays in ulab. Or did I interpret your question incorrectly? In any case, if the question is really about ulab, we should probably move it to https://github.com/v923z/micropython-ulab/issues.

[kmatch98]

Performance of bitmap_label.py is currently limited by the speed of bitmap copying of the individual glyphs into the bitmap_label.

I updated CircuitPython's displayio.Bitmap to provide a .insert function. This takes a slice of a "source" bitmap and copies it into the bitmap at a specified x,y location in the bitmap. My current fork is located here

Note: This version of bitmap.insert copies only non-zero values from the source over into the bitmap (specifically for copying glyphs and not copying the background pixels). This function could be extended to provide a parameter for what value to ignore or use None to copy all values.

Parameters for bitmap.insert:

• x: Horizontal pixel location in bitmap where source_bitmap upper-left corner will be placed
• y: Vertical pixel location in bitmap where source_bitmap upper-left corner will be placed
• source_bitmap: Source bitmap that contains the graphical region to be copied
• x1: Minimum x-value for rectangular bounding box to be copied from the source bitmap
• y1: Minimum y-value for rectangular bounding box to be copied from the source bitmap
• x2: Maximum x-value for rectangular bounding box to be copied from the source bitmap
• y2: Maximum y-value for rectangular bounding box to be copied from the source bitmap

My .insert code uses the C-side get_pixel and set_pixel bitmap functions to copy the source slice into the bitmap. I'm sure it could be optimized with word-sized writes, but even with this simplistic version it makes a huge difference. I'm unsure to verify how much additional storage is used by adding this function. Other cleanups required are to check the input parameter validity based on @jepler's instructions:

[deshipu]

@kmatch98 shouldn't that be called "blit"?

[kmatch98]

Never heard that until just now but after reading what it means it seems appropriate.

Is blit only for when background isn’t copied? Or is that generic enough term if the whole bitmap is copied over?

[deshipu]

It's a general term for transferring a block of pixels, with optional mask or other logic operations.

[kmatch98]

Closed with #3275