I don’t think this deserve its own topic so I’ll leave this here in case someone finds it interesting/useful. This is a demo for half height double buffering grayscale for Arduboy. I’m pasting here a copy of the text which is also included with the source code.
= Arduboy ssd1306 GDDRAM half-height double buffering demo
== Theory of operation
The number of displayed lines refreshed is reduced by setting
ssd1306’s COM mux ratio, in the example code below the mux ratio
is set to 32 lines (half of the maximum). Each height frame is
uploaded to the GDDRAM region not being rendered, then
the set display line offset command is used to display the newly
== Advantages and disadvantages
The set display line offset command takes effect between frames
so there is no tearing. However, the display is refreshed at
higher frequency (twice as fast in this example because the number
of lines is halved). When displaying grascale, and in order to minimize
flickering, the contents of GDDRAM have to be updated as fast as the
display’s frame rate. The exact frame rate is unknown, changes
with time (part tolerances, temperature, battery voltage) and there
is no mechanism available in “Arduboy V1” production hardware to
control ssd1306’s fosc or pace screen updates using some feedback
from ssd1306 . This in practice means that while there is no tearing,
flickering is unavoidable to some degree but this example may still
be useful for demos using grascale or cutscenes.
If anyone uses this technique it would be nice to be credited for it
unless this turns out to be something everyone knew already and I was
just late to the party!
== Full screen grayscale
I have investigated using this technique to achieve full screen
grayscale by alternating ssd1306 refresh between the top and
bottom half of the screen and my conclusion is that it is not viable.
The technique involves reducing the mux ratio to half-height as above
but both the start line offset and the screen display offset are changed
during display blanking so they are applied at the same time
between frames. Both commands involved take affect during blanking, but
it appears the set display line offset command takes effect on current frame+2
(i.e. during the second blanking period after the command is sent) so this
has to be taken into account.
While in the half screen case only one command is sent, in the full screen
case two commands are sent back to back and it is possible for the second
to be received too late to take effect in the next frame depending on the
exact timing the command is sent in relation to the blanking period. 
Additionally even if the non-atomicity of the two commands execution is ignored
the implementaiton needs to make sure it is sending exactly one command sequence
per frame which requires control of ssd1306’s fosc or a feedback mechanism to
notify the MCU of the blanking period neither of which is possible on "Arduboy V1"
production hardware. So the same issue that makes tearing unavoidable
when rendering the full screen at once exists in this case, only the effect
is visually worse than tearing because when the glitch occurs the bottom half
of the screen is rendered in the top half for a single frame before being corrected.
The overall effect of the glitch is at best a ghosting image of one half of the screen
appearing in the other half once in a while. Which is probably undesirable for
most applications unless the glitchy behaviour serves the theme of the application/demo
 The relevant pins are not available on the connector.
 Interestingly the fact that the set display line offset command
takes effect one frame later than expected would help working around
the non-atomicity of two sequencial commands in the case when the internal
registers they affect are latched between the reception of the two commands.
So this ‘unexpected’ (and undocumented) behaviour of the set display
line offset command may indeed be intentional.