Help adding E-Ink display support

Memory is always and issue: queuing image buffers for partial update could quickly throw you into out-of-memory hell.

Going w/ the queueing idea, I suggest the following when a) is possible:
a) Have a full buffer for the EDispay
b) Use the Graphics to update the buffer and queue the info about rectangle that has been changed
c) Have a worker that selects and transfers by the queued information from the buffer to the EDisplay

Caveats:

1. Regarding b) I don't know if the current Graphics implementation provides you with the rectangle information after a draw command. Depending of such implementation, it could feed that queue. May be on creation of the Graphics object, an additional parameter/option could be passed that provides that queue.
   
2. Lot's of small overlapping things, such updating the second hand in an analog clock, could become inefficient. Therefore, the algorithm that selects the rectangle to display could be smarter then just take what is next in queue, and calculate a new rectangle containing multiple rectangles to achieve a higher overall-efficiency.
   
3. Specific draw commands - specially for lines 'around' +45 and -45 degrees - could define multiple rectangles rather than one big one...
   
   

I'm not sure if this thread of thought leads somewhere useful... ;-) ... :\ ... :(

Quite some time ago when playing with a gps and a serially connected 320x240 260K color TFT, I ran into the issue of not having enough time between the 1s interval of inputs to update the screen... I resorted to store the gps info and only display where a changes was, and when I run out of time, to skip some of the changes: DIY Marine GPS using enhanced GPS Module, u-blox NEO-6M GPS receiver, and ILI9341 Module controlled 2.8" Color TFT LCD.