Thanks for posting this up -I'll have to diff and see what init values actually changed. Looks like we need some kind of options object to let this stuff be specified - although the module itself is quite small so I wonder whether we shouldn't just have another module for this slightly different type of display?
The row/col offsets could hopefully be added during initialisation as well - calculating offsets for each pixel write would really slow things down.
Q1: STM32F407VGT6
I think you're still going to be limited by SPI transfer speed. Until Espruino supports DMA you're not going to be able to push the data that fast.
Q2: would a mode with 'non palettes zones' & other stuff 'palettes' be of any interest ?
I'm not sure I understand... But if the other mode is unusable on all official Espruino boards because of the memory usage then I doubt it'd be that useful to people?
Q3: would a mod of the 'clear()' & 'flip()' methods accepting a rectangle x1,y1,x2,y2 be of any help ( to either clear or update only part of the screen ) ?
If you could make flip() use that information and only upload the area of the screen that had changed then I think that would be very useful! Although you may find that the extra code needed to crop line-by line slows it down - so it may be worth ignoring the X coordinates and sending only entire lines.
Q4: could 'dynamic italic text' be come a feature ?
Q5: could an alternative behavior for the 'palettes' mode be handy ? ( if color is outa bounds, fallback to either black or white depending on a param passed or settings )
Wouldn't that make everything really slow? And I'm not sure how it could be out of bounds - if you have a 4 bit image with 16 colours then they can't be out of bounds by definition??
Q6: best way to get 'instant drawing' for a (colored or not but likely ) logo ?
Just copy the contents of g.buffer using the Uint8Array.set method - This example 'Mario Game' does it to speed things up: http://www.espruino.com/Platform+Game
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.
Thanks for posting this up -I'll have to diff and see what init values actually changed. Looks like we need some kind of options object to let this stuff be specified - although the module itself is quite small so I wonder whether we shouldn't just have another module for this slightly different type of display?
The row/col offsets could hopefully be added during initialisation as well - calculating offsets for each pixel write would really slow things down.
I think you're still going to be limited by SPI transfer speed. Until Espruino supports DMA you're not going to be able to push the data that fast.
I'm not sure I understand... But if the other mode is unusable on all official Espruino boards because of the memory usage then I doubt it'd be that useful to people?
There is actually Graphics.getModified http://www.espruino.com/Reference#l_Graphics_getModified as Graphics keeps track of what has changed.
If you could make
flip()
use that information and only upload the area of the screen that had changed then I think that would be very useful! Although you may find that the extra code needed to crop line-by line slows it down - so it may be worth ignoring the X coordinates and sending only entire lines.I know what you mean, but I'm not convinced! You could write a function a bit like there is for doubling font size though? http://forum.espruino.com/conversations/327333
Wouldn't that make everything really slow? And I'm not sure how it could be out of bounds - if you have a 4 bit image with 16 colours then they can't be out of bounds by definition??
Just copy the contents of
g.buffer
using theUint8Array.set
method - This example 'Mario Game' does it to speed things up: http://www.espruino.com/Platform+GameOr if you want to save memory you could use heatshrink compress/decompress on it: http://www.espruino.com/Reference#l_heatshrink_compress