Turns out we need to add further states and transitions,
to establish full sync-link (backpressure) in both directions...
- need to introduce a third cursor since the callback from GUI-Thread can be late
- consequently also need a further state transition SHOW -> WAIT to create the barrier
- furthermore, need marker state STOP to halt playback after a short read (end-of-file)
- setup a IORING_OP_TIMEOUT to drive the frame loop
- use the status mark of buffers ahead to supply new IORING_OP_READ
- rely on two running framecount cursors with modulus to map onto buffer slots
Since I want to segregate the code according to the domain,
several methods must be provided to the video display to conduct
a properly synchronised handover of video pixel data; by using
`Glib::Dispatcher` as base class, all aspects of feed synchronisation
can be packaged into a single connection interface, without having
to share implementation details between the video display and player.
This implies a basic decision regarding the buffer and state data to use,
and how this can be defined, parameterised and passed between threads.
I decided to place separation of domains first and to prefer
using a functional callback over using a shared data structure.
leaning heavily on the similar structure used for last year's
FrOSCon talk regarding video output (by Benny Lyons and myself).
However, this time we'll use a process state object (the player)
and, furthermore, there is some cross-wiring of components involved...
Hereby I use the setup and framework from last year's FrOSCon talk
to bootstrap the demo example code for the talk at FrOSCon-26
Notably, the modern OpenGL output pipeline based on EGL is intended for reuse.
Insights in this code were based essentially on existing code bases under GPL.
Furthermore, using GPL is seen as a statement in support of "The Commons"
