Fractional display buffer for low-ram devices

[lhartmann]

Describe the problem you have/What new integration you would like

Allow low-memory devices to efficiently handle large-ish displays (e.g. ST7789V on ESP8266).

1. Allow DisplayBuffer to be a 1/N fragment of the total display area.
2. Allow DisplayBuffer to keep track of the current fragment offset.
3. Have Display::do_update_(...)update() loop for i in 0:N-1 times.
   3.1. Set clip rectangle to the i-th fragment.
   3.2. Set DisplayBuffer to the i-th fragment.
   3.3. Call the writer/draw functions.

Edit: Looping in the derived class' update() gives the driver more freedom to use fragmentation in hardware friendly ways, and requires no changes to Display or DisplayBuffer classes.

Memory usage drops to 1/N, but N calls to the writers are needed. You save RAM, pay with CPU.

Having N greater than 1 can cause side-effects if the writers are not idempotent.

Having N configurable allows the user to choose the best trade-off between RAM versus CPU.

Having N default to 1 will keep all current configurations with identical behavior, and avoid side-effects.

Please describe your use case for this integration and alternatives you've tried:

When using ST7789V on an ESP8266 (as on a geekmagick smalltv), the code tries to allocate a full framebuffer. It does not fit in RAM, so it fails. This has been mentioned by several people here (#901), on a ST7789V component page note, and on the forum.

Additional context

@rletendu proposed a framebuffer-less solution which works, but is (supposedly) slow and flickers during updates.

Old-school u8glib library had a nice approach for low-memory framebuffers: Factional buffers (which it calls pages), looping over different clipping areas, and repeatedly calling the update routine (which it calls draw) for each fraction. Something like the code below, where draw() is supposed to be idempotent.

  u8g.firstPage();  
  do {
    draw();
  } while( u8g.nextPage() );

[lhartmann]

Got this implemented as an external component for st7789v displays. The pull-request was aborted, though, as this is a deprecated driver.

Keeping the issue open while we don't have a driver-indepent implementation.