How should I structure a partial update for usability?

See more:

C++14

I have a really odd requirement for driving an e-ink/e-paper display.

Normally it does 2-bit (4-color) grayscale at 400x300.

However, in that mode it can only update the entire display at once, which takes quite awhile due to the nature of e-paper.

And yet, to support some minor animation it can do what are called "partial updates" wherein one small portion of the screen can be quickly drawn and redrawn.

This is how the Nook works when it has interactive components on its e-paper display.

The problem with the partial updates is they are sorely limited:

1. They can only be in black and white. Grayscale is not available, forcing me to treat a partial update surface as a different "canvas" with black and white instead of grayscale.

2. This is worse - the device will only update the display in x coordinates that are multiples of 8. Basically, the least significant 3 bits of the X coordinate start and end points are ignored. So I can start an update at x=0,x=8,x=16, etc. Similarly the widths must be multiples of 8. No such restriction exists on the y. Normally, you could work around this by reading part of the old framebuffer back into memory (so like if you start at x=5 then you read the first 8 bits from the framebuffer, and mask the last 3 bits before filling those 3 with new data), but that doesn't work here because the framebuffer is grayscale, and the partial update is black and white only.

3. I don't have a lot of RAM so my hope is to recycle the square of memory I'm using for to hold the existing grayscale framebuffer, even if it means I'm wasting 1 bit per pixel to do so.

So I have pretty severe restrictions on partial updates and I need some brainstorming to figure out how to best expose this before I go writing a bunch of code half cocked.


Basically I am thinking

auto drawTarget = myDriverInstance.partial_update({x1,y1,x2,y2});

And then you can draw to drawTarget in black and white.

The trouble is the coordinates. they won't be entirely respected. The last 3 bits are off for the x1,y1 values and on for x2,y2 regardless.

I can document this, but gosh I really am hoping for something better here.

I could error if the coordinates will not match the final coordinates but the problem with that is I'm using C style "error results are return values" and they're easily ignored, so I want to avoid throwing errors if I don't have to.

I might need a whole different approach. I fear I may have tunnel vision and I could just need to look at this a different way.

What I have tried:

I have not tried anything yet, though I did list an idea in the description.