-
• #27
yes, if you set x,y to start and then width to 1 and height to line length each new pixel should 'overflow' to next line
-
• #28
Hi, I have also being doing some measurements. I am using an M5StickC which has an 80x160 pixel ST7735S screen.
WithSPISENDMANY_BUFFER_SIZE=64
Displaying a 80x160FillRect
= 20ms
Displaying a 80x160drawImage
= 345ms.I thought there was room for improvement for drawImage so I implemented a version of
lcd_spi_unbuf
with a chunk buffer that is flushed to screen when it is full or when the address window is changed. Now the results are:With
SPISENDMANY_BUFFER_SIZE=80
- the size of the chunk buffer
Displaying a 80x160FillRect
= 19ms
Displaying a 80x160drawImage
= 61ms.Essentially the speed up is achieved by passing bigger chunks to the
spi_send_many
. The only disadvantage is that I have had to implement aflip()
routine ro flush the chunk buffer after the last graphics operation. For images this more than 5 time speed up is really worth it. I suspect it would also work for the horizontal line example.If the image is rotated, the performance disappears cf vertical lines, so perhaps we should see how that can be dealt with. However, rotation within an image is not a problem.
What would be the best way of letting you all look at the code?
-
• #29
What would be the best way of letting you all look at the code?
- Fork Espruino on github
- clone your fork to local disk
- create a branch for your fork
- add code to that branch
- push your code to that branch
share you branch via link.
- Fork Espruino on github
-
• #31
There was a bug in
flip()
- now fixed.
This optimization is perfect for drawing horizontal lines
Display 240x240(320)
before: 990ms, after 266ms
I guess it should be possible to optimize this for vertical line too?