Hi Roman
Background:
There are GLCDs were the internal frame buffer (display memory) can not be read by the microcontroller.
This is usually true for displays with SPI interface.
Solutions:
- Reserve memory in the microcontroller, render the picture into it and transfer the memory from the microcontroller to the display.
Disadvantage: Large SRAM consumtion, possible only if display frame buffer size is smaller than the available SRAM. - Reserve some smaller amount of memory (e.g. 1/4 of the display frame buffer size) and render the picture more often (e.g. 4x). This trades time vs. SRAM
Disadvantage: Slower frame rate, picture loop (more complex API)
U8glib was designed to support displays without read back ability.
U8glib follows solution 2)
U8glib is one of the view libs which support large SPI displays on small (ATTINY) controllers (with very limited SRAM).
A graphics lib such as GLCDv3 for KS0108 controller has a much more convinient programming interface. But GLCDv3 also depends on the fact that it can read memory from the display frame buffer.
U8glib offers a solution for displays not support by other graphics librarys.
U8glib sometimes is the only available lib.
U8glib might be a bad choice in other cases (like using it for KS0108 based displays)
I am glad to hear about success stories with U8glib and i am sorry to offer programming API, which is more complicated and difficult to understand.
I tried to compensate this with many features, a good collection of fonts, reliable functions and a documentation with many pictures.
I am always open to improvements, but i probably can not change its basic feature.
I also suggest to read Bill's remarks on GLCDv3 and u8glib:
More Information:
http://code.google.com/p/u8glib/wiki/tpictureloop
Thanks for your picture,
Oliver