user4783: I am creating a tiny game on my Arduino UNO with an Adafruit ST7735 1.8" TFT / SD breakout. I am performing screen operations using the built-in TFT-library.
The problem is screen flickering. Even though I take care to prepare data and minimize the time between clearing the screen and writing the new stuff to it, the screen "refresh()" is significant. I heard someone mention something called double buffering, so I read a bit up on it, but I am frankly clueless on how to implement it on an Arduino UNO. 
Is it possible to implement double buffering on an Arduino UNO to prevent screen flickering, and if so, how?
Libraries used:
#include <TFT.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>

The screen is "cleared" like this:
screen.background(0,0,0);  // Clear it
screen.text(buf, 10, 25);  // Write new stuff


user22924: To add to previous answers:
Double-buffering is an approach where you write to the actual device - but in an off-screen area. Then you switch to the new area in a single instruction, indistinguishable to the naked eye, rather than clear the visible area and write while it's still being displayed.
This requires that the device has extra memory to support the two areas: on-screen and off-screen. Absent that extra memory, then the best that you can do is pre-calculate as much as possible, and write to the screen as fast as possible.

user13432: 
How can I implement double buffering with an Arduino UNO?

Full screen double buffering (aka off-screen bitmap) for an ST7735 (128 x 160 x 16 bit color) would require 40 Kbyte. With only 2K byte SRAM on the Arduino Uno double buffering is not possible.
Some of the flickering is due to the Arduino core unoptimized SPI protocol and the graphics library. They could be optimized to reduce some of the flickering. 
Please see the Cosa ST7735 driver and SPI support for examples of high speed inter-leaving SPI transfer and graphics optimizations. 
Smaller mono-chrome screens (such as ST7565) can be supported with double buffering. An example is the Cosa OffScreen Canvas that can be used to create a bitmap that is transfered to the screen in a single operation. 
Cheers!

user313: If you're already preparing the next screen's-worth of data before you clear the screen, then double buffering won't help. In that case, the time taken to re-write the screen data is what causes the flicker, and the only way to improve it is to write the screen faster. If the software is to blame, it will be in screen.text(). If the software is already driving the hardware as fast as the hardware will go, then that's the best you can do.
Double-buffering would let you prepare the next screen while the currently-prepared one is loading (and will require interrupt-driven I/O to do it). The result would be more screen refreshes per unit time, but it doesn't sound like that is your problem.
One easy experiment to try is to not clear the screen before you re-write it, if that is possible to do. Then your next screen will overlay the current screen with (we hope...) no blanking period. That might prevent the blinking.

4783: <p>I am creating a tiny game on my Arduino UNO with an Adafruit ST7735 1.8" TFT / SD breakout. I am performing screen operations using the built-in TFT-library.</p>

<p>The problem is screen flickering. Even though I take care to prepare data and minimize the time between clearing the screen and writing the new stuff to it, the screen "refresh()" is significant. I heard someone mention something called double buffering, so I read a bit up on it, but I am frankly clueless on how to implement it on an Arduino UNO. </p>

<p>Is it possible to implement double buffering on an Arduino UNO to prevent screen flickering, and if so, how?</p>

<p>Libraries used:</p>

<pre><code>#include &lt;TFT.h&gt;
#include &lt;Wire.h&gt;
#include &lt;SPI.h&gt;
#include &lt;SD.h&gt;
</code></pre>

<p><br>The screen is "cleared" like this:</p>

<pre><code>screen.background(0,0,0);  // Clear it
screen.text(buf, 10, 25);  // Write new stuff
</code></pre>
 22924: <p>To add to previous answers:</p>

<p>Double-buffering is an approach where you <em>write to the actual device</em> - but in an off-screen area. Then you switch to the new area in a single instruction, indistinguishable to the naked eye, rather than clear the visible area and write while it's still being displayed.</p>

<p>This requires that the <em>device</em> has extra memory to support the two areas: on-screen and off-screen. Absent that extra memory, then the best that you can do is pre-calculate as much as possible, and write to the screen as fast as possible.</p>
 13432: <blockquote>
  <p>How can I implement double buffering with an Arduino UNO?</p>
</blockquote>

<p>Full screen <a href="https://en.wikipedia.org/wiki/Multiple_buffering" rel="nofollow noreferrer">double buffering</a> (aka <a href="https://stackoverflow.com/questions/7347367/whats-concept-of-off-screen-bitmap">off-screen bitmap</a>) for an ST7735 (128 x 160 x 16 bit color) would require 40 Kbyte. With only 2K byte SRAM on the Arduino Uno double buffering is not possible.</p>

<p>Some of the flickering is due to the Arduino core unoptimized SPI protocol and the graphics library. They could be optimized to reduce some of the flickering. </p>

<p>Please see the Cosa <a href="https://github.com/mikaelpatel/Cosa/tree/master/libraries/ST7735" rel="nofollow noreferrer">ST7735</a> driver and <a href="https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/SPI.hh" rel="nofollow noreferrer">SPI</a> support for examples of high speed inter-leaving SPI transfer and graphics optimizations. </p>

<p>Smaller mono-chrome screens (such as ST7565) can be supported with double buffering. An example is the Cosa <a href="https://github.com/mikaelpatel/Cosa/blob/master/libraries/Canvas/Canvas/OffScreen.hh" rel="nofollow noreferrer">OffScreen Canvas</a> that can be used to create a bitmap that is transfered to the screen in a <a href="https://github.com/mikaelpatel/Cosa/blob/master/examples/LCD/CosaST7565/CosaST7565.ino#L157" rel="nofollow noreferrer">single operation</a>. </p>

<p>Cheers!</p>
 313: <p>If you're already preparing the next screen's-worth of data before you clear the screen, then double buffering won't help. In that case, the time taken to re-write the screen data is what causes the flicker, and the only way to improve it is to write the screen faster. If the software is to blame, it will be in screen.text(). If the software is already driving the hardware as fast as the hardware will go, then that's the best you can do.</p>

<p>Double-buffering would let you prepare the next screen while the currently-prepared one is loading (and will require interrupt-driven I/O to do it). The result would be more screen refreshes per unit time, but it doesn't sound like that is your problem.</p>

<p>One easy experiment to try is to not clear the screen before you re-write it, if that is possible to do. Then your next screen will overlay the current screen with (we hope...) no blanking period. That might prevent the blinking.</p>
