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
@Andreas_Rozek, regarding performance...
I played around quite much with these serial displays - and with GPS: DIY Marine GPS using enhanced GPS Module, u-blox NEO-6M GPS receiver, and ILI9341 Module controlled 2.8" Color TFT LCD - and I have to say that it was also quite a while. Since then, the Espruino implementation to do things with serially attached displays as also quite much improved, last but not least also by more powerful chips used in Espruino boards and with newest kid on the block - bangle.js - an 8bit parallel bus is used vs single bit then. But this is all relative since we always expect more...
At that time, I used vector fonts... and all that vector calculation is performed by Espruino. To have decent display, I re-displayed only changed values trying to keep up with incoming data. But that was not enough. Therefore, I 'interleaved' the display of values: re-display only a subset of the values for each interval - you may remember the old (CRT) displays that had to interleave lines (for different reasons) to create a pleasant visual impression.
Many factors play into the performance of a application that includes visualization. In the end it boils down to:
For the last item, it matters a lot what the display controller has to offer and can be accessed - taken advantage - by the display controller controlling controller - Espruino.
For text / symbol / sprites display, today I would use different bit map fonts... and if the display controller has built-in or uploadable fonts, that's where I would head for... of course, a mute point for Mandelbrot graphics.
Furthermore: Does the display controller support and expose copy commands and have memory that can be written to but is not displayed - or not displayed at all times? Similar question is: can the display controller be configured to use only a portion of its memory and scale it up to the full size of the display - of course of cost of pixelation? If latter is no the case, performance improvements are limited to what the pixel generation side can do, which is calculate one pixel and transmit that pixel 4 times to cover 4 display pixel with one calculation. Of course it will not happen as for transmissions, because those by their nature would eat away what just has been saved by calculation. That's when double buffering comes into place, which works for widgets very well... but may becomes a mute point when there is only on widget and its size is of the full screen. I said 'may', because it depends wether you can wait for the whole widget/screen to be ready and then displayed 'in an instance' or are you interested in seeing rendering progress...
Therefore, following answer and statement still hold:
It all depends!andWhat are you interested in?