You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
Drawing a rectangle vs drawing it with 4 lines is faster because a rectangle is always aligned with x and y (x or y constant for any of the lines and y and x is increasing/decreasing integer) and there is never the question which pixel to turn on, where as a line can have have x and y changing because a line can have a slope, and much more math and decision making is involved. Line drawing could be optimized by looking at the slope and have different implementation for it, line one for where either x1 and x2 or y1 and y2 are equal, slope modulo is equal, less or more than 45 degrees.
Large smooth fonts use a lot of space. Since you need though only digits, it is significantly less than a complete character set. Furthermore, your 7-segment pic gives me the idea of combining defining (masked) graphics (buffers) of each segment and then copy the segments into the display buffer - like composing the digits - before sending out the display buffer.
Espruino 2v10 just introduced bit blit Graphics.blit() for such a thing... unfortunately it has no mask / transparency support... so you have to build that for yourself to be able to copy overlapping rectangles into a target buffer where only part of the source buffer should override. If you write some inline C it will be very fast... Next, you have to find a display that is not single. bit serially controlled but parallels to 8 or 16 bits (depending the GPIO pins you can spend/waste on the display...
Inline C is easy and very fast... I did some it in the conversation about Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings. Since you do not need all the colors, you can use a very small source buffer of just 2 bits color depth and copy into the 'full-color' tarbet buffer according the target buffer's color depth. *in graphics below, the blue background inside the red box of each of the segments is considered transparent and pixels of it will not overwrite the corresponding target pixels.
Feedback from @Gordon: there are already provisions for that using .drawImage(...), .asImage(...), and more.
1 Attachment