Replies: 5 comments 7 replies
-
The changes you're requesting are a very narrow use case and would cause more confusion than help to most users. I suggest you create a fork of the repo for you to experiment. If you really need to trim down this memory, then the target platform probably should work with GIF images. |
Beta Was this translation helpful? Give feedback.
-
For normal GIF images, MAX_CODE_SIZE is a fixed value. 12-bit codes require a table with 4096 entires. If you make GIFs with smaller LZW tables, you could change that value, but it wouldn't be able to decode standard files. The color palette is a tiny amount of RAM compared to the other buffers. Saving a couple of hundred bytes mostly is just a rounding error. |
Beta Was this translation helpful? Give feedback.
-
Can you state why your are interested in shaving off a few bytes here and there? Do you have a very constrained system that doesn't have enough RAM? Maybe GIF isn't the right format to use for your task. |
Beta Was this translation helpful? Give feedback.
-
I understand your use case, but it's too specific to you to potentially disturb things for the average user. I think it would be best for you to make a fork and then you're free to modify it any way you want. |
Beta Was this translation helpful? Give feedback.
-
There is another optimization to be made: |
Beta Was this translation helpful? Give feedback.
-
Can we add a section to the wiki regarding RAM optimization?
The following things are unclear:
MAX_CODE_SIZE
how big does it need to be for a given screen size and palette? What does this actually do?MAX_COLORS
: what happens if we set a smaller value than an image actually has? E.g.MAX_COLORS
16 but image has 255 colorsOptimization idea:
unsigned short pPalette[(MAX_COLORS * 3)/2]
: I don't know why this is* 3 / 2
. Shouldn'tMAX_COLORS * 2
be sufficient for 16-bit RGB565?Beta Was this translation helpful? Give feedback.
All reactions