From ce2c3d2c0603957116e6f038b2051fc1e510268f Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 29 Jun 2026 23:13:33 +0200 Subject: [PATCH] Invocation: draft a generalised output context ...the plan is to wrap the `DataSink` and also to expose possible further control parameters here... Rather difficult to get started, since mostly related to ''planned features'' --- src/steam/engine/render-output-ctx.hpp | 64 +++++++++++ src/vault/out/timings.hpp | 2 +- wiki/thinkPad.ichthyo.mm | 150 +++++++++++++++++++++++-- 3 files changed, 204 insertions(+), 12 deletions(-) create mode 100644 src/steam/engine/render-output-ctx.hpp diff --git a/src/steam/engine/render-output-ctx.hpp b/src/steam/engine/render-output-ctx.hpp new file mode 100644 index 000000000..22ec53b5f --- /dev/null +++ b/src/steam/engine/render-output-ctx.hpp @@ -0,0 +1,64 @@ +/* + RENDER-OUTPUT-CTX.hpp - output control parameters for rendering + + Copyright (C) + 2026, Hermann Vosseler + +  **Lumiera** is free software; you can redistribute it and/or modify it +  under the terms of the GNU General Public License as published by the +  Free Software Foundation; either version 2 of the License, or (at your +  option) any later version. See the file COPYING for further details. + +*/ + + +/** @file render-output-ctx.hpp + ** A configuration context with output control parameters for render processing. + ** This context parameter store is associated with the [calculation streams](\ref CalcStream) + ** and accessed from the [render node invocation](\ref RenderInvocation) to retrieve additional + ** and context dependent settings for aspects beyond the automated parameters and the actual + ** render function. Notably the output DataSink is abstracted and the corresponding target + ** data buffer is exposed through this context. + ** @todo »Playback Vertical Slice« -- effort towards first integration of render process ///////////////////TICKET #1221 + ** @todo 6/2026 still not entirely decided regarding the organisation of Render Job parameters; + ** introducing such a context seems a good way to retain some limited flexibility while + ** keeping matters focused. + */ + + +#ifndef STEAM_ENGINE_RENDER_OUTPUT_CTX_H +#define STEAM_ENGINE_RENDER_OUTPUT_CTX_H + +#include "steam/common.hpp" +#include "vault/mem/buffhandle.hpp" +#include "vault/out/output-slot.hpp" +#include "lib/time/timevalue.hpp" +#include "lib/nocopy.hpp" + + +namespace steam { +namespace engine{ + + using lib::time::Time; + using vault::mem::BuffHandle; + + + + /** + * Render output control parameters and configuration details. + */ + class RenderOutputCtx + : util::MoveOnly + { + using Output = vault::out::OutputSlot::DataSink; + Output sink_; + + public: + BuffHandle getOutputBuffer (Time absoluteNominalTime); + }; + + + + +}} // namespace steam::engine +#endif /*STEAM_ENGINE_RENDER_OUTPUT_CTX_H*/ diff --git a/src/vault/out/timings.hpp b/src/vault/out/timings.hpp index 9f5ec79ca..895613922 100644 --- a/src/vault/out/timings.hpp +++ b/src/vault/out/timings.hpp @@ -52,7 +52,7 @@ namespace lib { namespace time{ class Quantiser; - typedef std::shared_ptr PQuant; + using PQuant = std::shared_ptr; }} namespace vault { diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index eb5a36bfb..3e3360afb 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -90026,6 +90026,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + + + + + + + + + + @@ -117313,6 +117331,85 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + +

+ Name: »RenderOutputCtx« +

+ + + + + + + + + + +

+ Ein Render-Job, der nicht Daten in einen Buffer produziert, erscheint mir ziemlich hypothetisch, denn das ist hier das mentale Modell schlechthin. Insofern war ich immer davon ausgegangen, daß man einen OutputSlot nur belegt, wenn man ihn auch braucht — und daß man ihn immer braucht zum Rendern. +

+ + + + + + + +

+ ...und nicht einmal da wirklich, da es nicht viele Tests gibt, die einen Render-Job explizit als Job aufrufen; entweder ist es sowiso ein Mock-Job, oder wir rufen den Node-Pull direkt auf. +

+ + + + + + + + + + + + + + + +

+ ...denn was soll so ein »Parameter« überhaupt für einen Wert liefern? Das ganze Thema »parameter-descriptors« für die Automation habe ich lediglich in die Zukunft verschoben, und nehme derzeit nur an, daß man da dann ein System bauen kann.  +

+ + + + + + + +

+ ich brauche aber jetzt eine Anschluß-Stelle für später... +

+ + + + + +

+ der processKey war da eine so schöne Design-Lösung: es war nur irgendein Key-Wert, und dazu konnte man was von einem „geplanten Map-Zugriff“ sagen. Schön plausibel und stellt keinerlei Gefahr dar, weil man damit überhaupt nichts anfangen kann. Wie ein Leer-Rohr, das man schon mal duch die Wand gelegt hat. Leider ist diese schöne »Lösung« jetzt inhaltlich sinnlos geworden, und ich müßte nun viel konkreter darstellen, was hier „geplant“ ist (wovon ich aber keinen Plan habe) +

+ + + + + + + + + @@ -117345,7 +117442,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)

- Also beschließe ich: das ist eine »Probe-Intgration« + Also beschließe ich: das ist eine »Probe-Integration«

@@ -117543,15 +117640,20 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - - + + + + + + + + - + @@ -117621,7 +117723,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -117639,7 +117741,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -117702,9 +117804,17 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - + + + + + + + + + @@ -117727,6 +117837,20 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + +

+ ...die zwar in einer architektonischen Betrachtung sehr sinnvoll erscheint, (noch) keinen konkreten Gehalt hat, aber leider jetzt bereits einigermaßen komplex gebaut ist. Und ich möchte so bauen, daß sich die weitere Entwicklung von selbst ergibt, und zukünftige Möglichkeiten derzeit keine Probleme verursachen.... +

+ + + + @@ -118006,7 +118130,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -118157,6 +118281,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + @@ -126934,8 +127062,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - +