-
Notifications
You must be signed in to change notification settings - Fork 38
Add bitmap_label.py
library for reduced memory usage for displaying text
#79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…is, but wanted to make a commit in case I happend to lose anything.
I commited some updates to resolve some of the pylint errors on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is close to ready, but I do think there are a few things we can finish up.
There are a few small tidying up things to take care of that are leftover from cookie-cutter.
There are a few tweaks to _memory_saver
configuration that I think I'd like to make.
And possibly add a simpletest example, and/or change up the existing ones a bit.
The one other thing that comes to mind now is I think we should provide all of the same properties as the other label.py like color
, background_color
, text
etc... I think most of them can be copied from the existing one Mostly from around here and below in the existing label.
I can help with making these changes tomorrow night.
I updated the getters and setters to match I have a couple of pylint errors that I'm not sure how to resolve. These are three setters (font, text, line_spacing) that only return errors. I suspect it is flagging these functions because they don't use the input variables or any references to
Here is the code I used to verify the operation of the getters/setters:
|
I think it's okay to add the pylint ignore inside of those three functions to disable the Although I'm also curious how hard it would be (or if there is any downside) to allow those properties to be mutable by having them call |
Good point maybe if the bitmap is recreated then it will should work fine. Just have to be sure it releases the previous bitmap so it can get garbage collected. Keep me posted on what you find. |
I got dug into it some and I see it's going to be a bit more difficult that I was thinking to make them mutable at least for I think we will need to recreate the tilegrid too possibly, and do some calculations to figure out the correct size again. Which will mean that we need a few of the parameters to be stored as class variables so that they can be accessed outside of I think it's a good goal to make them mutable at some point if we can, but I'm not sure it's worth holding up this PR for it. For now I do think it's okay to add the pylint ignores since those methods currently are only provided for API matching and to throw the error letting the user know that they aren't mutable. They don't need to use |
Ok, I just pushed with the Future: Maybe this should be an issueI agree that making it mutable will take some time. I've never done anything with actively freeing up instances, so that will be new ground. But I'll spend my time working on getting the bitmap.blit function cleaned up before returning to this. |
simplifying example scripts. Awesome!
I merged your last changes and all passed the checks. I like the quote on the comparison example. I think I resolved all of your Review changes that you requested, but double check. Otherwise, I think this is good to go. |
I hunted for the Strange glyph loading memory usage and remembered why. For determining the ascender/descender height, It checks the max dimensions of several glyphs: M, j, space, and ‘ apostrophe. So it’s best to load these four glyphs are loaded in the |
I looked over the current version tonight and it looks good to me. I'll mark it approve after you get that last change in and we can see if we get any other feedback prior to merging |
Ok, I just updated the examples and passed the checks. Let me know what else you find that needs updates. Future enhancements:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me at this point. Thanks for working on this Kmatch98!
Awesome. Thanks for your help working on this! |
Updating https://github.com/adafruit/Adafruit_CircuitPython_EPD to 2.7.0 from 2.6.2: > Merge pull request adafruit/Adafruit_CircuitPython_EPD#41 from makermelissa/master > Merge pull request adafruit/Adafruit_CircuitPython_EPD#40 from makermelissa/master Updating https://github.com/adafruit/Adafruit_CircuitPython_Display_Text to 2.8.1 from 2.8.0: > Merge pull request adafruit/Adafruit_CircuitPython_Display_Text#83 from FoamyGuy/fix_anchored_position_rounding > Merge pull request adafruit/Adafruit_CircuitPython_Display_Text#85 from kmatch98/glyph_speedup > Merge pull request adafruit/Adafruit_CircuitPython_Display_Text#79 from kmatch98/bitmap_label > Merge pull request adafruit/Adafruit_CircuitPython_Display_Text#81 from kmatch98/anchor_fix
I created this new
bitmap_label.py
library as a drop-in replacement forlabel.py
but it uses less memory.This new library uses a bitmap to store text. It has been calibrated against the position of
label.py
.I include two examples that can be used to compare the two versions. The new library consistently uses less memory than the equivalent text in
label.py
. This can be evaluated directly using the example filedisplay_text_label_vs_bitmap_label_simpletest.py
which also displays the amount of memory utilized.Other impacts:
The speed of using the
bitmap_label
library is inferior compared to the existinglabel
library, primarily limited by the current of copying the bitmap glyphs. This bitmap copy performance is the subject of a related issue with display.io.