@cr0sh
Unfortunately, it is not early in the game as far as design and coding goes.
When designing something like this, in order to get fast efficient code, you have to go one way or the other.
There are advantages to either method. As Michael said the biggest issue with using a framebuffer architecture is that it consumes quite a bit of memory. In fact to do anything really nice you actually need multiple buffers for different "planes".
With multiple planes you can do fancy things like scroll text on top of the graphics or have different animations on different layers.
There simply is not enough RAM memory in AVR chips to support frame buffers especially for larger displays.
It really is something that can not be "optional". Well ok, it could be but
in order to really take advantage of a frame buffer architecture, it really needs to be different code for the low level and especially the text rendering code. Yes the current text code and graphic code could run on top of a frame buffer "as is" but it would not be as efficient compared to what is possible.
Currently the routines would need a bit of a re-write to take advantage of direct access to frame memory, as currently they assume indirect page based memory access and do alot of extra things to ensure things are bundled up and packaged into lcd page bytes. This is because the LCD memory interface is SLOW compared the speed of the AVR, so it is advantageous timewise for the AVR to do a few extra instructions to ensure that the glcd write pipeline is not broken and reads are avoided as much as possible. This page logic and indirect function call overhead to access the data is simply not needed when updating a local frame buffer.
In reality, a frame buffer is not always faster. It may sound counter intuitive but in many real world situations it will be no faster and can actually be slower than what the current code is doing as the current code only updates those lcd pages that are being changed vs updating the entire display or even a region of the display.
Along with some fancy multiple graphic "planes" features,
the biggest thing that a frame buffer architecture can do is time shift when the display update gets done rather than actually improving display update performance speed.
I have a long post about this in the other ks0108 thread on page 27, 5th from the top.
Now a couple of the things we could do that would be very easy and is actually on our "to do" list is to have some sort of alternate DrawBitmap() function that takes a pointer to a RAM buffer address rather than a FLASH address. Or perhaps some kind of ram buffer dump routine
so that people could then experiment with their own frame buffer code.
Adding that kind of functionality would be quite easy.
--- bill