#1387 new todo

Memory handling scheme for render buffers

Reported by: Ichthyostega Owned by:
Priority: normal Milestone: 0integration
Component: lumieraSteam Keywords: render steam roadmap VerticalSlicePlayback
Sub Tickets: #824, #834, #1363, #1367, #1396, #1428, #1429, #1430 Parent Tickets: #905, #1369, #1370, #1392, #1412

Description

As a Lumiera developer,
I need a consolidated scheme for dealing with temporary and output buffers,
to be able to pass invocation from a Render Job into the Render Nodes.

consolidation of framework drafts

Several years ago, as part of the initial (stalled) efforts to build a Render Node invocation, and later the (still valid) foundation of the Player subsystem, two similar and partially overlapping handling protocols were defined:

  • Buffer Provider Protocol
  • Output Slot Protocol

The latter even re-uses a concept introduced for the former: the BuffHandle front-end to be used by client code.

The integration efforts for the »Playback Vertical Slice« however uncovered some discrepancies in the intended usage of these protocols: notably the OutputSlot provides a DataSink and expects that the client invokes DataSink::emit(FrameID, BuffHandle) when data is ready for output. Yet the Buffer Provider Protocol defines another function BuffHandle::emit() — and obviously the code in the Render Nodes will invoke the latter, since it can not even know when a given BuffHandle represents an output.

Another shortcoming unveiled by the integration effort is the very much prototype-y nature of the default implementation, which unfortunately was tied-in much too tightly with the interfaces. Notably, the BufferProvider relies directly on a BufferMetadata table attached as an implementation component to track the buffer's state transitions — which makes usage in a highly concurrent environment quite challenging.

The Concepts and protocols as such seem valid and should be retained; the task is rather to loosen the overly tight coupling to the default implementation and to change the interface design in a way to make both protocols better composable.

Change history (6)

comment:1 by Ichthyostega, at 2025-02-03T20:58:46Z

blocking: 905, 1369, 1370905, 1369, 1370, 1392

comment:2 by Ichthyostega, at 2025-02-19T15:26:53Z

blockedby: 824, 834, 1363, 1367824, 834, 1363, 1367, 1396

comment:3 by Undercover Agent, at 2025-12-25T00:00:00Z

blockedby: 824, 834, 1363, 1367, 1396
blocking: 905, 1369, 1370, 1392
Parent Tickets: 905, 1369, 1370, 1392
Sub Tickets: 824, 834, 1363, 1367, 1396

comment:4 by Ichthyostega, at 2026-02-19T16:51:47Z

Parent Tickets: 905, 1369, 1370, 1392905, 1369, 1370, 1392, 1412

Attach to parent #1412 (clarify the role of Buffer Types).

comment:5 by Ichthyostega, at 2026-05-12T01:03:50Z

Sub Tickets: 824, 834, 1363, 1367, 1396824, 834, 1363, 1367, 1396, 1429

Add subticket #1429 (control effort for global buffer allocator).

comment:6 by Ichthyostega, at 2026-05-12T16:58:07Z

Sub Tickets: 824, 834, 1363, 1367, 1396, 1429824, 834, 1363, 1367, 1396, 1428, 1429, 1430

Add #1428 + #1430

(Render-buffer pools).

Note: See TracTickets for help on using tickets.