Closed andrewjswan closed 2 months ago
This opens a lot more possibilities, like giving each character one color or calculated gradients per character etc.
It seems to me that such a solution will consume a lot of memory, and will also increase the delay, because we will need to output letter by letter and set the color each time... But at the same time we will also need to get an array of colors for each letter.
I thought about the solution for a long time, but I did not find a simple, effective and fast one that would fit into the concept of the current screens. But we can always try to optimize, improve and change this functionality.
I will try to add my idea to the queue constructor, this is where this step really belongs to. It will cost some RAM but the timming will cause problems at the long run, with sensors etc.
This PR adds flexibility to that functionality and a better example in the documentation. If you change the concept, it is better to use these changes as a basis.
@lubeda Ant news?
I still don't like the effects off this feature but the feature it self is nice.
Is there a way to analyze the text and the colors once instead of every draw cycle? This is slowing down everything in the loop.
perhaps with two arrays: filled on_next_screen
one for the string and the other for the RGB color.
Like
The A is red, B is green, C is blue,
This opens a lot more possibilities, like giving each character one color or calculated gradients per character etc.