Because the display is bistable the library should hide the on() and off() functions. Let the library call them when needed, why bother the user with it. In other words, let the library do the energy management! OK with external power this would mean overhead but I guess the complexity of both functions are minimal.
Good idea. It's possible that a user will want to control that themselves (e.g. back-to-back commit()s of small image areas; the "big brother" of this display is 132x64), but probably unlikely. Speaking of power management, an #ifdef for the PinChangeInt library (if available) to sleep until the display update is finished would reduce power usage quite a bit. I was in kind of a 'get er done' mood for this first release
Could a breakout board be build with sensor to do this automagically?
Maybe! The breakout board linked above actually has pads for an optional thermistor and cap that could be read by measuring the time constant across them, but I haven't tested this yet. The temp comp table from the manufacturer only has steps of 5degC anyway, so it need not be too accurate.
pixmap(int x, int y, const char * pImg)
How it knows the size? or is it full screeen?
It's the same format as a GLCD image - the width and height are encoded as the first 2 bytes of the image.
Is it possible to read out the display to see the commit() is done? Or is commit async?
There is a BUSY pin that can be polled (or tied to an interrupt) to see if the display charge pump has finished pumping (about 300ms) and again to see when commit is done. Handling this in a smarter way (the current version just polls for it) is definitely on my todo list
clearEndOfLine(x,y); to partially clear the (text) display, not a must but a nice to have.
setPixel(x,y) , getPixel(x,y)
Is this possible?
Unfortunately not, on this display at least. Several limitations currently in the library (e.g. text and images aligning on 8-pixel vertical page boundaries) stems from the fact that the display RAM is not readable on this display. This makes a read-modify-write operation impossible without maintaining a local framebuffer (something I steered clear of for now in interest of memory footprint, although it may be an option in the future).