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.
GLCD also has a write-through cache option which creates a frame buffer that it uses for reads
instead of reading the data from glcd memory which can speed up display updates at the expense
of using additional memory.
Turning on the write-through cache also allows GLCD to work the same on write-only displays at the expense of the
memory for the frame buffer. I've thought about creating a shift register interface that could reduce
the number of pins down to 2-3 pins but have never gotten around to it.
Maybe there are some optimizations that could be done to speed up u8glib or offer more capabilities.
For a little speed:
- maybe provide hints to the low level PAGE_NEXT function as to which area(s) are "dirty" and need updating.
It could be as simple as a low and high value that indicates the starting page and ending page
that needs to be pushed to the display.
Or it could be as complex as a bitmap indicating which bytes have pixel data to be flushed out.
The low level code could choose to ignore the hints but smarter lower level update routines could
choose to take advantage of it to reduce updates.
Seems like the simple low/high hints would be pretty easy to implement and might offer some
significant speed improvements in certain situations.
- Could it treat the page buffer as a write through cache instead?
Seems like a pretty big change but that would allow only writing the modified pages to the display.
Form some additional functionality:
- Could it create a full frame buffer to provide additional functionality?
Without write-through, it seems like it wouldn't be that difficult to wedge in.
The code could use all the same mechanisms it does now, so none of the lower interface code
has to change. The difference being it would simply always have the rows of data always available.
The flush code could call the PAGE_NEXT (flush) routines as necessary for each row in the frame buffer
to update the physical display.
This would allow for the possibility for things like scrolling or graphic updates on top of existing pixels.
It's always a tradeoff. Some strategies work better than others depending on the nature
of the display updates being done.