RFC: Loading images from SPI flash about tinybmp HOT 5 CLOSED

Great to hear that you made progress. Unfortunately I'll be away for the next two weeks and don't have time to look at the code until I'm back.

@jamwaffles: Perhaps you could take a look at this and finish the review of PR #28, which the new code is based on.

from tinybmp.

Sorry for not replying earlier, but tinybmp development has stalled at the moment.

Being able to draw a BMP file directly from an external source without having to buffer the entire image first would be a very useful feature. If you want to try to implement this you should base it on the code in PR #28, which changes the way the pixels in the BMP file are accessed.

from tinybmp.

@rfuest Thank you for the feedback and the pointer to that PR. I'll review and report back.

from tinybmp.

@rfuest I've made good progress on this, but I'm stuck very close to the finish line...

I wrote a new BmpReader trait that provides a method to read() into a caller-provided buffer as well as a buffered_read() method to be used by a new BmpReaderIterator. The read() call is used to load just the BMP header into a buffer. This buffer must be kept around for the lifetime of the Bmp structs. The buffered_read() and associated iterator were an attempt to generalize ChunksExact so it could work with things other than byte slices. The internal buffer would hold one row at a time, and implement an Iterator that could be easily (ha!) plugged into the RawColors iterator.

This approach requires RAM for (1) the BMP header and (2) a single BMP row. The example image I'm working is 5730 bytes and only would require 130 + 27 bytes of RAM to load instead of the full slice of 5730 bytes. (The RAM for the embedded_graphics display would still be needed, but that's a different battle).

(1) Is working well. I implemented a from_reader() function that does the trick. Passes the tests that just involve the BMP header.

(2) Is problematic. I wrote an iterator that can load data one row at a time, which is invoked by the next() method in the iterator. The problem is that I cannot feed this iterator into RawDataSlice() as the latter expects a &[u8] instead of the generic Ref<'_, u8> item that the iterator generates (a cell::Ref is required because the internal buffer is inside a RefCell).

I'd love some feedback on this approach and (ideally!) a solution to my problem with Ref lifetimes and the RawDataSlice(). Maybe you can suggest someone to look at the code? I'm keeping my work in this branch of my tinybmp fork.

Cheers!

from tinybmp.

I finally found a workaround to reduce the RAM requirements: I can read my images in smaller tiles from flash and calling draw() once for each tile. This way the image is never stored entirely in memory. So, I'll abandon this work. The repo branch will stay up in case anyone is interested in picking up that effort.

from tinybmp.