Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

add arbitrary rect drawing from bitmaps/canvases (RGB 565, RAM only) #442

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

aremmell
Copy link

For the project I am working on (a compositing window manager which uses Adafruit GFX/Arduino GFX Library as its underlying graphics driver layer), I have the need to draw only certain parts of a memory buffer/canvas containing the pixels to render to the display hardware (using the optimized hardware class' drawing routines).

As far as I can tell, there is currently no way to do that cleanly: I can only do an un-optimized loop and draw individual pixels, or call Adafruit_SPITFT's setAddrWindow and writePixels, but those are not part of the Adafruit_GFX interface (I may just change my underlying requirement to the SPITFT class instead of the GFX interface if this PR is unwanted).

In order to resolve this situation, I:

  • Added an additional drawRGBBitmap function to Adafruit_GFX as well as Adafruit_SPITFT (to utilize its optimized drawing routine) that takes the following additional parameters:

    • src_x the x offset into the bitmap/canvas to begin reading from
    • src_y the y offset ""
    • src_w the actual width of the bitmap/canvas (used to move the read pointer forward by a scan line)
  • Retrofitted the existing version of drawRGBBitmap to simply call the new one with default arguments, resulting in the same behavior as before the change

Limitations

  • I have only implemented this for the RAM-resident RGB 565 routines. If you guys are keen on taking the change, I would be glad to do the others as well, but this is the only one I need for now.

I tested to make sure that the existing interface works as expected when calling with 0,0 for x,y and the bitmap's width and height, but I did not test edge cases like negative x,y or invalid width/height values. I did the best I could to mimic the logic that was already in place.

If more formal testing and proof that I didn't break anything is required, let me know and I will write something up.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant