Consider making the busy waits into aspects of sync/async updates

[nyaray]

In the original source, busy waiting is an option, likely depending on the single threaded nature of normal python programming, but the reasons don't really matter.

Since our library will be wrapped in a GenServer, we should probably make it an option to busy-wait on the display (maybe as an opts field in set/show calls?) when handling synchronous show requests, whether set or show.

[lawik]

So could we do things like this for an async flow:

1. Pixels are pushed to the device, do the whole update dance and push the pixels to be displayed
2. Go back to waiting for the user to send new pixels.
3. Receive new pixels, check that the device is ready to receive, if not start busy-waiting to push this update.
4. If another update of pixels is received, replace the current planned pixels with the new, but it just goes into the same update-sequence that is already started.

Does that make sense? Then if the device is ready we just check the busyflag, get the OK and push pixels. Otherwise we wait on the busy-flag to flip back and on the next push we push the latest pixel update. Otherwise we'll just trigger a lot of slow refreshes in sequence. Which feels dumb.

[nyaray]

Firstly, I agree in that we should not be pushing pixels willy-nilly and immediately drawing by default.

Secondly, a question:

1. Pixels are pushed to the device, do the whole update dance and push the pixels to be displayed

... did you mean "Pixels are pushed to the GenServer [...]"?

---

So, there's two axes of (a)sync, in my mind:

1. GenServer call or cast, that is, the server is either expected to respond, or not.
   • Pretty much a regular call or a fire-and-forget, to the GenServer
2. Inky immediate or deferred drawing, the Inky GenServer draws immediately when pixels are received.
   • Either (attempt to!) push the pixels in the GenServer state immediately, either by giving up after one busy_read or doing a busy_wait, or later, whenever the GenServer's internal logic decides to do it, deferred, or, finally, not at all. the last case requires that show be called at some point to show pixels.

I've sent a photo of a diagram of these thoughts. I think it can be handled within the scope of the GenServer-ification

[lawik]

Woo, this turned into tons of discussion on Slack. But generally, Emilio has done thinking and should roll forth :)

I have committed to complain about naming.

[lawik]

Note from shouting about it, states for the update? option for set_pixels:

• :state_only: do not push to display, just update pixel state
• {:timeout, :once}: Use genserver timeouts to avoid multiple updates. When the timeout triggers, update the display if not busy. Otherwise just updates pixel state.
• {:timeout, :await}: Use genserver timeouts to avoid multiple updates. When the timeout triggers, await device ready with a busy wait and then push to the display.
• :once: Check if busy once, return timeout if failed, otherwise push to display. Update pixel state regardless.
• :await: Busy wait until you can push to display.

[lawik]

New results of our discussion. We start with a stupid simple approach and revisit this when we've some more runtime for the project to actually determine reasonable needs.

[nyaray]

AH! Yes, as an option to set_pixels the name update makes complete sense! Glårijus!

Re: stupid simple API: see top comment at #11 , which has been edited.

[nyaray]

I think we can close this issue, if you agree, please close it @lawik