Feature Request: Non-blocking PicoGraphics update() for Inky Frame

[LionsPhil]

More-or-less what it says on the tin, and especially for the Inky Frame where the work being waited on is a ~40-second operation happening on the display controller. Either something like

display.update(blocking = False)

or

display.set_blocking(False)
display.update()

Exposing a matching is_busy() and/or busy_wait() would help use this safely.

Reasoning: I have a thin-client which does two things that are interacting unfortunately here:

• update()ing the image to blank before setting image data and update()ing again, to work around e-ink burn-in
• Streaming the image data from a network socket directly to PicoGraphics' framebuffer

That means the socket has to be held open, effectively buffering the image in the network, until that first update() has finished the e-ink dance---and makes having reasonable timeouts tougher. Ideally, the sequence would be:

• Clear the framebuffer, and set the eink controller update()ing, non-blocking
  • The blocking wait is already controllable in the inky73 driver, just not exposed up through PicoGraphics. (It also has the desired is_busy()/busy_wait().)
  • (As far as I can tell, the earlier wait shouldn't be conditional, since if execution proceeds past that with the controller still busy, commands will just get ignored---or worse, some of them ignored if it becomes ready midway.)
• At this point the image data has already been sent to the controller, so start overwriting the PicoGraphics framebuffer with the streamed decode from the network, and close and finish that off.
• Block for the first update() to have completed, then start a second to send and display the new framebuffer contents.

(Yes, the network contents could be buffered to system RAM, flash, or an SD card, but only the latter reliably has enough space, and the framebuffer is right there to save the writes and further power overhead if PicoGraphics wasn't busy-waiting. :) )