Add new method drawBitmapFast with better performance #458
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added faster drawBitmap that uses TFT auto-increment address feature
Change name to drawBitmapFast instead
Fix no image shown by drawBitmapFast
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added a new method drawBitmapFast in Adafruit_SPITFT which is esentially a copy of the Adafruit_GFX drawBitmap but with much better performance. This is achieved by setting up the address window for the whole image; not for each pixel.
Performance is about 8 times higher.
The method applies clipping so that only the portion of the image that is within the display bounds is written.
Code has been tested with various X/Y offsets to verify that clipping is properly applied.
Note that I was forced to create a copy because of the stated limitations of Adafruit_GFX. I would rather change the Adafruit_GFX method, but that would require adding some abstract methods (e.g. for setting up the window) which would break backward compatibility.
This change is related to this issue: #415