Add failure check when opening next URing slot for a submission;
this ''can'' fail when the ring is fully populated -- which in theory
should never happen in our setup, yet can always, in practice...
''Review supported by Claude Code''
Control flow logic was scrutinised, and a race identified
in the solution to pass on the display action to the GUI thread.
Reconsidering the design, cross-thread synchronisation is now
hinged rather on a single atomic buffer pointer, where the GUI
thread notifies back completion of display work by setting that
pointer to NULL. Overall this simplifies the control logic
----
As an aside, I setup an outline of topics for documentation in `DemoSpec.txt`
and then instructed Claude to fill in the paragraphs, based on insight gained
as part of the code validation / review. Furthermore, I requested to generate
some diagrams that could be useful later when preparting the presentation
- use a helper class with a series of timer variables
- these can be addressed like the buffer ring »slots«
- commit each individual measurement into an EMA
No fundamental problem discovered thus far...
- GTK-3 does not resize the window, need to `set_size_request()` (instead of `resize()`)
- forgot to set slot-state to READ ⟹ submissions flood the full queue
- condition to allow frame display was too tight, thus slipping at first frame
- forgot to submit follow-up read tasks
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"
