Possible display draw call improvements

[JohnDoneth]

For the project I'm working on I wanted to take a framebuffer approach. I was having quite a hard time filling the entire screen instead of just half. After a while I realized the draw calls simply weren't providing enough data to fill the entire screen.

let framebuffer: [u8; 128 * 128] = [0xFF; 128 * 128];

display.set_draw_area((0, 0), (display_width, display_height))?;
display.draw(&framebuffer)?;
// not enough data, only half of the screen is populated. 

versus

let framebuffer: [u8; 128 * 128] = [0xFF; 128 * 128];

display.set_draw_area((0, 0), (display_width, display_height))?;
display.draw(&framebuffer)?;
display.draw(&framebuffer)?;
// The screen is now full of data as intended

What do you think about providing a convenience draw function that takes a &[16] slice of a buffer that splits the u16's into upper and lower u8's before sending them over the wire?

Also, an error being thrown if not enough data is being provided might be a good improvement; since we know the size of the area and how many bytes should be needed. But if that were implemented now, it doesn't seem like I would be able to call draw twice to workaround this general issue as doubling the passed buffer size doesn't populate the entire screen either.

// Simply doubling the framebuffer size like this does not work for me, and seems to hang.
let framebuffer: [u8; 128 * 128 * 2] = [0xFF; 128 * 128 * 2];

[MabezDev]

Whilst I'm not against this new function I can't help but think you would be better served by running the display in graphics mode where you can use embedded_graphics primitives to fill the display. Obviously this crate doesn't yet support buffering but I don't think it would be too hard to do.

Would that fit your use case?

[MabezDev]

I've just pushed v0.2.0 which includes feature gated frame buffer support, maybe this could work for you?

[JohnDoneth]

@MabezDev Awesome! I'm excited to try it out.