Closed ariep closed 4 years ago
I've been meaning to implement this, hopefully will this week!
a quick note---since there are only 16 allowed levels of grayscale anyway, it seems like 8bpp is kind of useless. Also, 3bpp doesn't pack pixels any more efficiently than 4 bpp. So my plan was to just automatically switch to 2bpp when doing an update that doesnt use all 16 grayscale levels (e.g. when update with DU display mode), and just use 4bpp otherwise. Thoughts?
a quick note---since there are only 16 allowed levels of grayscale anyway, it seems like 8bpp is kind of useless.
Quite true. However, creating an image is easier for me using the 8bpp format, because I can use CAIRO_FORMAT_A8
and can pass the cairo buffer contents directly to the display driver. I may later switch to 4bpp for faster image transmission, but for now using 8bpp meant a lower barrier to get something working.
So my plan was to just automatically switch to 2bpp when doing an update that doesnt use all 16 grayscale levels (e.g. when update with DU display mode), and just use 4bpp otherwise.
Sure, that sounds like a nice optimisation.
Sounds good!
By the way, this weekend I hope to finish a rewrite of some of the backend that will include pixel packing code into the SPI communication code, so you should be able to just pass it 8 bpp buffers and pick whatever transmission bpp you want, and it will pack the pixels for you without any overhead. Will update!
fixed with 99f803b200872d6daf21e502b164956a4d6ff879. Note that the backend automatically packs the pixels for you, so if your input is 1 pixel per byte, that is perfect. You can pass any pixel format you want and it will pack it to that before sending it to the device :)
In
load_img_area
, the pixel format is currently hardcoded to 4 bits per pixel. It would be nice to make this a function argument so you can actually use a different format, which seems to be otherwise supported.