lucadentella / SPIFFS_ImageReader

5 stars 5 forks source link

When drawing to TFT, transact = false results in nothing drawn #5

Closed frdfsnlght closed 5 months ago

frdfsnlght commented 2 years ago

Running on an ESP32. My display (SSD1351) is on the SPI3 bus (VSPI) and works fine, even drawing images from SPIFFS using your library. Image drawing is not the fastest thing, so in an attempt to speed it up, I passed the last parameter, transact, as false to the drawBMP method. The SPI3 bus is only connected to the TFT so I figured there's no need for the transactions. But now no images are drawn.

Is this a known problem? Or am I doing something wrong?

lucadentella commented 1 year ago

Hi

I admit I never tried to set it to FALSE... If I understood, you used the exact same code, and - changing only the transact parameter, it didn't render anything, is it correct?

frdfsnlght commented 1 year ago

Sorry for taking so long to respond; I've been out-of-country.

Yes, you are correct. Setting to false with no other changes renders nothing.

Also, further analysis of my project yielded more insight into the speed "problem". Turns out, the big time sink is reading from SPIFFS, not rendering the result. Your library renders much more quickly if I preload the images. But, alas, I can't do that without running out of memory. I've got 20 images, each one being a 24KB BMP file. Rendering while streaming from SPIFFS takes about 200-300ms per image. I don't have the render-only time handy anymore due to big changes in my project.

My ultimate solution was to ditch your library in favor of my own. Your library is fine for what it's intended to do, but I realized, due to the nature of my images, I could write an optimized library. My images are greyscale line art from Inkscape (SVG), exported to PNG (about 12KB each). I wrote some python code to convert the PNG to a custom format that results in files in the 200-900 byte range (5 bit greyscale, RLE encoded). Rendering these from SPIFFS takes about 30ms each, but since they're so small, I can preload them into memory and render at 6ms each.

Anyway, thanks for looking at this, but it won't effect my project at this point. Maybe someone else might benefit though?