Range checking was not done to make it faster and smaller. What I figured is with only 20x16 pixels, it should be kind of hard to get too crazy anyway. But, if range checking doesn't add much to the code, it would be a simple process to add.
That shouldn't add to much code, the only place that is needed is to avoid a division by zero which would cause the AVR to crash.
This is kind off in the line method, a simple if ( ( x2 - x1 ) == 0 )
to avoid the division by 0. One thing that strikes me is why do you use a float in the line method? You should be able to get away with just using a uint8_t or byte and would avoid having to pull in the floating point library.
modify the magic numbers that you have about the code by defines, #define BITMAP_X_SZ 20
I don't exactly follow what you mean by this. Do you mean don't use 20, 16 and 8, etc. as they repeat in many places but instead use a define instead? I assume the reason is for memory or speed for micro controllers?
This is a bit more for clarity, readability and maintainability. It will not add any speed improvements, nor additional code but it will make things a bit easier to follow. For example:
#define USER_DEF_CHARS 8 // Number of LCD user defined characters
#define USER_CHAR_LEN 8 // Bitmap length for each LCD user defined character
for (byte c=0; c<USER_DEF_CHARS; c++)
for (byte a=0; a<USER_CHAR_LEN; a++)
As I said, just being picky here.
Years of being the only programmer on projects had resulted in poor comment skills. I typically don't add comments unless it's for me to remember how I did something. It's hard for me to even read code with comments in it. I typically remove comments from other people's code so I can see what is going on. With that said, yes, I probably need some comments here and there.
I guess it is to help future users more than anything.
I downloaded and installed tortoisehg last night but haven't had a chance yet to look at it. I sure hope it doesn't update the code on the site till I tell it to because I'm one to change source 500 times a day, delete entire pieces of code, rewrite it a different way, then erase everything and go back the way it was.
Nothing gets pushed to the repo unless you tell it to. The nice thing is that you can work on a file or two and if you don't want to commit the changes you can alway go back to the previous version. I think is a nice thing to use even for home hobby project.
The only optimization right now, is to save a bit on memory by having a true byte bitmap, nothing much.
I would remove from the examples, or from the library begin method, the duplicate, lcd.clear, ... In any case, when the LCD is initialized the screen is cleared, with no cursor, and with no blinking either. But that is not any performance improvement in the sense that the it is only done during initialization.
As an update, I have tried it on my LCD I2C backpack, it is not as speedy but the animations work great.