ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: forge a path for integration

Browse source 
Facing quite some difficulties here, since there are (at least)
two abandoned past efforts towards building a render node network
in the code base; the structure and architecture decisions from these
previous attempts seem largely valid still, yet on a technical level,
the style of construction evolved considerably in the meantime. Moreover,
these old fragments of code, written during the early stages of the
project, were lacking clear goals and anchor points at places;
the situation is quite different now in this respect.

Sticking to well proven practice, the rework will be driven by a test setup,
and will progress over three steps with increasing levels of integration.
This commit is contained in:
Fischlurch 2024-04-22 23:13:55 +02:00
parent 47e26e2a65
commit a11ee34fc8
7 changed files with 515 additions and 29 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
tests/46node.tests
View file

@ -6,13 +6,21 @@ PLANNED "Proc Node basics" NodeBasic_test <<END
END
PLANNED "Proc Node fabrication" NodeFabrication_test <<END
PLANNED "Proc Node development" NodeDevel_test <<END
END
PLANNED "Proc Node fabrication" NodeFactory_test <<END
END
PLANNED "Proc Node connectivity" NodeLinkage_test <<END
END
PLANNED "Proc Node input reading" NodeInput_test <<END
END
PLANNED "Proc Node operation modes" NodeOperation_test <<END
END
PLANNED "source reading Node" NodeSource_test <<END
END

59
tests/core/steam/engine/node-devel-test.cpp Normal file
View file

@ -0,0 +1,59 @@
/*
NodeDevel(Test) - verify proper render node operation and calldown
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
This program 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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file node-devel-test.cpp
** unit test \ref NodeDevel_test
*/
#include "lib/test/run.hpp"
//#include "lib/util.hpp"
//using std::string;
namespace steam {
namespace engine{
namespace test {
/***************************************************************//**
* @test check render node operation modes and collaboration.
*/
class NodeDevel_test : public Test
{
virtual void run(Arg)
{
UNIMPLEMENTED ("operate some render nodes as linked together");
}
};
/** Register this test class... */
LAUNCHER (NodeDevel_test, "unit node");
}}} // namespace steam::engine::test

10
tests/core/steam/engine/node-fabrication-test.cpp → tests/core/steam/engine/node-factory-test.cpp
View file

@ -1,5 +1,5 @@
/*
NodeFabrication(Test) - building render nodes
NodeFactory(Test) - building render nodes
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
@ -20,8 +20,8 @@
* *****************************************************/
/** @file node-fabrication-test.cpp
** unit test \ref NodeFabrication_test
/** @file node-factory-test.cpp
** unit test \ref NodeFactory_test
*/
@ -42,7 +42,7 @@ namespace test {
/***************************************************************//**
* @test creating and wiring various kinds of render nodes.
*/
class NodeFabrication_test : public Test
class NodeFactory_test : public Test
{
virtual void run(Arg)
{
@ -52,7 +52,7 @@ namespace test {
/** Register this test class... */
LAUNCHER (NodeFabrication_test, "unit node");
LAUNCHER (NodeFactory_test, "unit node");

10
tests/core/steam/engine/node-source-test.cpp → tests/core/steam/engine/node-input-test.cpp
View file

@ -1,5 +1,5 @@
/*
NodeSource(Test) - unit test of the source reading render node
NodeInput(Test) - unit test of the source reading render node
Copyright (C) Lumiera.org
2008, Hermann Vosseler <Ichthyostega@web.de>
@ -20,8 +20,8 @@
* *****************************************************/
/** @file node-source-test.cpp
** unit test \ref NodeSource_test
/** @file node-input-test.cpp
** unit test \ref NodeInput_test
*/
@ -42,7 +42,7 @@ namespace test {
/***************************************************************//**
* @test the source reading render node.
*/
class NodeSource_test : public Test
class NodeInput_test : public Test
{
virtual void run(Arg)
{
@ -52,7 +52,7 @@ namespace test {
/** Register this test class... */
LAUNCHER (NodeSource_test, "unit node");
LAUNCHER (NodeInput_test, "unit node");

59
tests/core/steam/engine/node-linkage-test.cpp Normal file
View file

@ -0,0 +1,59 @@
/*
NodeLinkage(Test) - verify proper render node operation and calldown
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
This program 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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file node-linkage-test.cpp
** unit test \ref NodeLinkage_test
*/
#include "lib/test/run.hpp"
//#include "lib/util.hpp"
//using std::string;
namespace steam {
namespace engine{
namespace test {
/***************************************************************//**
* @test check render node operation modes and collaboration.
*/
class NodeLinkage_test : public Test
{
virtual void run(Arg)
{
UNIMPLEMENTED ("operate some render nodes as linked together");
}
};
/** Register this test class... */
LAUNCHER (NodeLinkage_test, "unit node");
}}} // namespace steam::engine::test

29
wiki/renderengine.html
View file

@ -6183,7 +6183,7 @@ This is the core service provided by the player subsystem. The purpose is to cre
:any details of this processing remain opaque for the clients; even the player subsystem just accesses the EngineFaçade
</pre>
</div>
<div title="PlaybackVerticalSlice" creator="Ichthyostega" modifier="Ichthyostega" created="202303272236" modified="202404192303" tags="overview impl discuss draft" changecount="38">
<div title="PlaybackVerticalSlice" creator="Ichthyostega" modifier="Ichthyostega" created="202303272236" modified="202404222258" tags="overview impl discuss draft" changecount="39">
<pre>//Integration effort to promote the development of rendering, playback and video display in the GUI//
This IntegrationSlice was started in {{red{2023}}} as [[Ticket #1221|https://issues.lumiera.org/ticket/1221]] to coordinate the completion and integration of various implementation facilities, planned, drafted and built during the last years; this effort marks the return of development focus to the lower layers (after years of focussed UI development) and will implement the asynchronous and time-bound rendering coordinated by the [[Scheduler]] in the [[Vault|Vault-Layer]]
@ -6206,17 +6206,22 @@ __May.23__: taking a //prototyping approach// now, since further development was
* ✔ implement a »~Split-Splice« algorithm for &amp;rarr; SegmentationChange, rigged accordingly to generate a mocked Segementation for now
* ✔ create a testbed to assemble a JobPlanningPipeline step by step (&amp;rarr; [[#920|https://issues.lumiera.org/ticket/920]] and [[#1275|https://issues.lumiera.org/ticket/1275|]])
__June23__: building upon this prototyping approach, the dispatcher pipeline could be rearranged in the form of a pipeline builder, allowing to retract the originally used implementation scheme based on »Monads«. The implementation of the Dispatcher is complete, yet the build up of the [[»Render Drive« #1301|https://issues.lumiera.org/ticket/1301]] could not reasonably be completed, due to lack of a clear-shaped ''Scheduler interface''.
__June.23__: building upon this prototyping approach, the dispatcher pipeline could be rearranged in the form of a pipeline builder, allowing to retract the originally used implementation scheme based on »Monads«. The implementation of the Dispatcher is complete, yet the build up of the [[»Render Drive« #1301|https://issues.lumiera.org/ticket/1301]] could not reasonably be completed, due to lack of a clear-shaped ''Scheduler interface''.
__July23__: this leads to a shift of work focus towards implementing the [[Scheduler]] itself.
__July.23__: this leads to a shift of work focus towards implementing the [[Scheduler]] itself.
The Scheduler will be structured into two Layers, where the lower layer is implemented as //priority queue// (using the STL). So the most tricky part to solve is the representation of //dependencies// between jobs, with the possible extension to handling IO operations asynchronously. Analysis and planning of the implementation indicate that the [[scheduler memory managment|SchedulerMemory]] can be based on //Extents//, which are interpreted as »Epochs« with a deadline. These considerations imply what steps to take next for building up Scheduler functionality and memory management required for processing a simple job
* ✔ build a first working draft for the {{{BlockFlow}}} allocation scheme [[#1311|https://issues.lumiera.org/ticket/1311]]
* ✔ define and cover the basic [[Activities|RenderActivity]] necessary to implement a plain-simple-Job (without dependencies)
* ✔ pass such an Activity through the two layers of the Scheduler
* 🗘 establish a baseline for //performance measurements//
* ✔ establish a baseline for //performance measurements//
* ⌛ adapt the [[job planning pipeline|JobPlanningPipeline]] implemented thus far to produce the appropriate {{{Activity}}} records for the scheduler
__December23__: building the Scheduler required some time and dedication, including some related topics like a [[dedicated memory management scheme|SchedulerMemory]], rework and modernisation of the [[#1279 thread handling framework|https://issues.lumiera.org/ticket/1279]], using a [[worker pool|SchedulerWorker]] and developing the [[foundation for load control|SchedulerLoadControl]]. This amounts to the creation of a considerable body of new code; some &amp;rarr;[[load- and stress testing|SchedulerTest]] helps to establish &amp;rarr;[[performance characteristics and traits|SchedulerBehaviour]].
__December.23__: building the Scheduler required time and dedication, including some related topics like a [[suitable memory management scheme|SchedulerMemory]], rework and modernisation of the [[#1279 thread handling framework|https://issues.lumiera.org/ticket/1279]], using a [[worker pool|SchedulerWorker]] and developing the [[foundation for load control|SchedulerLoadControl]]. This amounts to the creation of a considerable body of new code; some &amp;rarr;[[load- and stress testing|SchedulerTest]] helps to establish &amp;rarr;[[performance characteristics and traits|SchedulerBehaviour]].
__April.24__: after completing an extended round of performance tests for the new Scheduler, development focus is shifted now shifted upwards to the [[Render Node Network|ProcNode]], where Engine activity is carried out. This part was addressed at the very start of the project, and later again -- yet could never be completed, due to a lack of clear reference points and technical requirements. Hope to achieve a breakthrough rests on this integration effort now.
* 🗘 establish a test setup for developing render node functionality
* ⌛ introduce a middle layer for linking the JobTicket to the actual invocation
* ⌛ rework and complete the existing node invocation code
!Decisions
;Scheduler
@ -7382,19 +7387,21 @@ A special operational condition mentioned above is the ''Scheduler Emergency''.
&amp;rarr; [[Rendering]]
</pre>
</div>
<div title="SchedulerRequirements" modifier="Ichthyostega" created="201107080145" modified="201112171835" tags="Rendering spec draft discuss">
<div title="SchedulerRequirements" modifier="Ichthyostega" created="201107080145" modified="202404212325" tags="Rendering spec draft discuss" changecount="1">
<pre>The [[Scheduler]] is responsible for geting the individual [[render jobs|RenderJob]] to run. The basic idea is that individual render jobs //should never block// -- and thus the calculation of a single frame might be split into several jobs, including resource fetching. This, together with the data exchange protocol defined for the OutputSlot, and the requirements of storage management (especially releasing of superseded render nodes &amp;rarr; FixtureStorage), leads to certain requirements to be ensured by the scheduler:
;ordering of jobs
:the scheduler has to ensure all prerequisites of a given job are met
;job time window
:when it's not possible to run a job within the defined target time window, it must be marked as failure
;failure propagation
:when a job fails, either due to an job internal error, or by timing glitch, any dependent jobs need to receive that failure state
:when it's not possible to run a job within the defined target time window, it should be silently dropped
;event propagation
:when some job is done, or due to an external event, a //notification// must be propagated to dependent jobs
;guaranteed execution
:some jobs are marked as &quot;ensure run&quot;. These need to run reliable, even when prerequisite jobs fail -- and this failure state needs to be propagated
:some jobs are marked as »compulsory«. These need to run reliable, even when prerequisite jobs fail -- and this failure state needs to be propagated
;superseding groups of jobs
:jobs can be marked as belonging to some group or stratum (called the »manifestation«); such a group can be masked out at a central registry, causing all the affected jobs to be //silently dropped//.
!detecting termination
The way other parts of the system are built, requires us to obtain a guaranteed knowledge of some job's termination. It is possible to obtain that knowledge with some limited delay, but it nees to be absoultely reliable (violations leading to segfault). The requirements stated above assume this can be achieved through //jobs with guaranteed execution.// Alternatively we could consider installing specific callbacks -- in this case the scheduler itself has to guarantee the invocation of these callbacks, even if the corresponding job fails or is never invoked. It doesn't seem there is any other option.
The way other parts of the system are built, requires us to obtain a guaranteed knowledge of some job's termination. It is possible to obtain that knowledge with some limited delay, but propagation of this information needs to be absolutely reliable (violations leading either to segfault, or memory leaks). The requirements stated above assume this can be achieved through a combination of //compulsory jobs// and //notifications.// Alternatively we could consider using a separate messaging system within the engine (the »EngineObserver«), which shall also be used for timing observations, higher level capacity management and for signaling exceptional operational failures.
</pre>
</div>
<div title="SchedulerTest" creator="Ichthyostega" modifier="Ichthyostega" created="202312281814" modified="202404182232" tags="Rendering operational draft img" changecount="170">

359
wiki/thinkPad.ichthyo.mm
View file

@ -79513,12 +79513,12 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<arrowlink COLOR="#fc5172" DESTINATION="ID_1834678491" ENDARROW="Default" ENDINCLINATION="-410;29;" ID="Arrow_ID_139741662" STARTARROW="None" STARTINCLINATION="-339;0;"/>
<linktarget COLOR="#ff3681" DESTINATION="ID_1642755650" ENDARROW="Default" ENDINCLINATION="-874;84;" ID="Arrow_ID_846448701" SOURCE="ID_1433064275" STARTARROW="None" STARTINCLINATION="-223;-228;"/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1699563656019" ID="ID_1361396246" MODIFIED="1699566672294" TEXT="Job-Planung mu&#xdf; aus Konsistenzgr&#xfc;nden in einem Job laufen">
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1699563656019" ID="ID_1361396246" MODIFIED="1713709497438" TEXT="Job-Planung mu&#xdf; aus Konsistenzgr&#xfc;nden in einem Job laufen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...damit sie das Grooming-Token hat und damit Zugriff auf die Scheduler-Ressourcen. Au&#223;erdem ist damit ein konsitenter Rahmen sichergestellt: geplante Startzeiten sollten fr&#252;hestend 20ms danach beginnen
...damit sie das Grooming-Token hat und damit Zugriff auf die Scheduler-Ressourcen. Au&#223;erdem ist damit ein konsitenter Rahmen sichergestellt: geplante Startzeiten sollten fr&#252;hestens 20ms danach beginnen und k&#246;nnen (einschlie&#223;lich Deadline) h&#246;chstens ein Fenster von ~20 Sekunden &#252;berspannen
</p>
</body>
</html></richcontent>
@ -79978,12 +79978,329 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
</node>
<node CREATED="1713661237357" ID="ID_5368181" MODIFIED="1713661263421" TEXT="habe anscheinend die &quot;buff handle logic&quot; in 2011 komplett umgekrempelt"/>
</node>
<node CREATED="1713794992321" ID="ID_267762321" MODIFIED="1713795160403" TEXT="dieser Test enth&#xe4;lt aber bereits die Quintessenz des neuen Buffer-Protokolls">
<arrowlink COLOR="#3c61b7" DESTINATION="ID_900623108" ENDARROW="Default" ENDINCLINATION="-475;-40;" ID="Arrow_ID_245920004" STARTARROW="None" STARTINCLINATION="-218;8;"/>
<icon BUILTIN="idea"/>
</node>
</node>
</node>
<node CREATED="1713711220441" ID="ID_1706159559" MODIFIED="1713711225557" TEXT="Dokumentation lesen">
<node CREATED="1713711236238" ID="ID_1078036041" MODIFIED="1713711237267" TEXT="NodeOperationProtocol">
<node CREATED="1713711238327" ID="ID_1353161349" MODIFIED="1713711245530" TEXT="sehr abstrakt gehalten"/>
<node CREATED="1713711247455" ID="ID_1684665301" MODIFIED="1713711263713" TEXT="das Konzept best&#xe4;tige ich zu 100% als valide">
<icon BUILTIN="yes"/>
</node>
<node CREATED="1713711268940" ID="ID_58785075" MODIFIED="1713711292672" TEXT="Unklarheiten bez&#xfc;glich der &#xbb;DataSink&#xab; vs. Buffer-Handle">
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1687302645431" ID="ID_1377069136" MODIFIED="1687302651074" TEXT="Aufruf-Schnittstelle"/>
<node CREATED="1713716080560" ID="ID_1140997216" MODIFIED="1713716082108" TEXT="RenderMechanics">
<node COLOR="#5b280f" CREATED="1713716083216" ID="ID_264756254" MODIFIED="1713716111215" TEXT="&#x2014; partiell obsolet gekennzeichnet &#x2014;">
<icon BUILTIN="stop-sign"/>
</node>
<node CREATED="1713716112683" ID="ID_1842023337" MODIFIED="1713716128262" TEXT="das UML-Klassendiagramm sieht strukturell sinnvoll aus"/>
<node CREATED="1713716128930" ID="ID_1697592841" MODIFIED="1713716132573" TEXT="ja die Namen....">
<node COLOR="#d20494" CREATED="1713716137963" ID="ID_1918966244" MODIFIED="1713716167447" TEXT="(ochnee &#x2014; naming and cache invalidation here)">
<font NAME="SansSerif" SIZE="10"/>
<icon BUILTIN="smiley-oh"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713716178243" ID="ID_963083918" MODIFIED="1713716198671" TEXT="StateAdapter &#x27fc; StateClosure">
<icon BUILTIN="yes"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713716200831" ID="ID_1149448314" MODIFIED="1713716213811" TEXT="BuffTable &#x27fc; FeedManifold">
<icon BUILTIN="yes"/>
</node>
</node>
<node CREATED="1713716868553" ID="ID_1136069824" MODIFIED="1713716878875" TEXT="ist aber alles sehr gut, was da in dem Text steht"/>
<node CREATED="1713716882999" ID="ID_73961827" MODIFIED="1713716940376" TEXT="(gut ist auch, da&#xdf; fast nix &#xfc;ber die Implementierung geschrieben wurde)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...mit der bin ich n&#228;mlich heute &#252;berhaupt nicht mehr d'accord...
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1713736666909" ID="ID_1897375430" MODIFIED="1713736668239" TEXT="RenderImplDetails">
<node CREATED="1713736669365" ID="ID_1902730004" MODIFIED="1713736680893" TEXT="m&#xe4;h"/>
<node CREATED="1713736684680" ID="ID_1641726803" MODIFIED="1713736715791" TEXT="beschreibt eine Implementierung die nicht recht wei&#xdf;, wo sie hin will"/>
<node CREATED="1713736716524" ID="ID_1186414782" MODIFIED="1713736723494" TEXT="heute w&#xfc;rde ich das nicht mehr so machen"/>
<node CREATED="1713736724175" ID="ID_1273508457" MODIFIED="1713736738080">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
insofern wichtig f&#252;r einen <b>2.Anlauf</b>
</p>
</body>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1713741181434" ID="ID_1452626869" MODIFIED="1713741183262" TEXT="BufferProvider">
<node CREATED="1713741184087" ID="ID_676222874" MODIFIED="1713741227941" TEXT="ja &#x2014; das ist der 2.Entwurf von 2011 &#x2014; und viel zutreffender im Gesamtverst&#xe4;ndnis">
<icon BUILTIN="forward"/>
</node>
<node CREATED="1713742350320" ID="ID_1837542949" MODIFIED="1713742375316" TEXT="impliziert auch ein Buffer-Handling-Protokoll (unklar zu welchem Grade bereits implementiert)"/>
<node CREATED="1713742540587" ID="ID_1934327577" MODIFIED="1713742560313" TEXT="alles 100% noch valide (und hinreichend abstrakt formuliert)"/>
</node>
<node CREATED="1713742101141" ID="ID_716691378" MODIFIED="1713742108608" TEXT="BuffHandle">
<node CREATED="1713742564543" ID="ID_900021322" MODIFIED="1713742570490" TEXT="geh&#xf6;rt direkt zum Buffer-Provider"/>
<node CREATED="1713742790928" ID="ID_1107336740" LINK="#ID_1354248617" MODIFIED="1713742849975" TEXT="Vorsicht: Handles haben einen ref-Count (Problem ist bekannt)">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1713742571198" ID="ID_92255782" MODIFIED="1713742678699" TEXT="die Idee mit der Meta/Descriptor-ID ist gut &#x2014; bedarf aber weiterer Kl&#xe4;rung"/>
</node>
<node CREATED="1713742921783" ID="ID_8372846" MODIFIED="1713742922923" TEXT="BufferMetadata">
<node CREATED="1713742924175" ID="ID_343152444" MODIFIED="1713742934747" TEXT="da hab ich mir wohl damals so einige Gedanken gemacht..."/>
<node CREATED="1713742935285" ID="ID_1810442720" MODIFIED="1713742956581" TEXT="klingt alles erst mal gut &#x2014; kann aber nicht sagen wie relevant es tats&#xe4;chlich ist"/>
<node CREATED="1713742957434" ID="ID_1517298653" MODIFIED="1713742971608" TEXT="hab den Eindruck, ich habe hier ein offenes, symbolisches Schema vorgesehen"/>
<node CREATED="1713742972326" ID="ID_1592129443" MODIFIED="1713742985662" TEXT="dann w&#xfc;rde sich das sp&#xe4;ter durch den eigentlichen Nutzen noch kl&#xe4;ren"/>
<node CREATED="1713742986571" ID="ID_1098578366" MODIFIED="1713743004178" TEXT="anscheinend ist ein solcher Nutzen bereits durch den OutputManager vorgegeben"/>
</node>
</node>
</node>
<node CREATED="1713711064227" ID="ID_672666235" MODIFIED="1713711069918" TEXT="Feststellungen">
<node CREATED="1713711073065" ID="ID_1795961167" MODIFIED="1713711103370" TEXT="der Fokus der Entwicklung bewegt sich nun wieder an den unteren Rand des Steam-Layers"/>
<node CREATED="1713711153009" ID="ID_1437136149" MODIFIED="1713711212977" TEXT="der dokumentierte Ansatz erscheint valide &#x2014; aber es ist weniger Substantielles da, als erhofft"/>
<node CREATED="1713711355610" ID="ID_977818766" MODIFIED="1713711563085" TEXT="es gibt einen Zwischenschritt: die Planungs-Phase &#x2014; diese l&#xe4;uft intermittent">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das erscheint mir als eine wichtige neue Einsicht: wir haben keine Zweiteilung (in Planung vs. Ausf&#252;hrung), sondern eine dreistufige Organisation:
</p>
<ul>
<li>
Builder &#10236; Render-Node network
</li>
<li>
Job-Planning &#10236; JobTicket + Closure
</li>
<li>
Invocation &#10236; pull-linkage
</li>
</ul>
</body>
</html></richcontent>
</node>
<node CREATED="1713716993583" ID="ID_26837068" MODIFIED="1713737900458" TEXT="diese mu&#xdf; auch einen Ausf&#xfc;hruns-Plan bereitlegen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
beinhaltet all die Verbindungen, die bis zuletzt flexibel bleiben m&#252;ssen und f&#252;r jeden einzelnen Aufruf durchgegangen werden, um die korrekten Verbindungen herzustellen; beispielsweise Verbindungen, die noch von einem Schalter oder von Automation abh&#228;ngen, oder Verzweigung infolge des Cache-Zustands
</p>
</body>
</html></richcontent>
<font NAME="SansSerif" SIZE="12"/>
<node CREATED="1713717920157" ID="ID_201859142" MODIFIED="1713744093809" TEXT="&#xbb;turnout system&#xab;">
<arrowlink COLOR="#483e74" DESTINATION="ID_863347622" ENDARROW="Default" ENDINCLINATION="456;0;" ID="Arrow_ID_1595016691" STARTARROW="None" STARTINCLINATION="426;67;"/>
</node>
<node CREATED="1713718003250" ID="ID_137160155" MODIFIED="1713718025070" TEXT="to establish the linkage for processing"/>
</node>
<node CREATED="1713736853226" ID="ID_1211099522" MODIFIED="1713736858430" TEXT="obsolete Ideen">
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1713736859658" ID="ID_731059768" MODIFIED="1713738016587" TEXT="&#xbb;pull-processing&#xab; im w&#xf6;rtlichen Sinn">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...denn das w&#228;re im direkten Widerspruch zu dem Builder-Ansatz; denn klassischerweise versteht man unter &#187;pull-processing&#171; eine <i>lazy evaluation,</i>&#160;eine <i>late discovery</i>&#160;&#8212; diese zielt im Kern darauf, eben genau keine ersch&#246;pfende Planung vorneweg zu machen. Das &#187;pull principle&#171; ist ein eleganter Implementierungs-Ansatz, der erstaunlich komplexe Funktionalit&#228;t abbilden kann, ohne eigentlich vorher eine strukturierte Analyse und Vorbereitung zu machen; jedes Teil definiert nur seine Vorraussetzungen, und auf geheimnisvolle Weise findet die Berechnung ihren Weg, wenn man nur lange genung &#8222;saugt&#8220;. Tats&#228;chlich ist es mir sogar im Gegenteil ein Anliegen, &#252;berhaupt nichts mehr zur Laufzeit &#8222;herauszufinden&#8220;. Ich ziele vielmehr auf eine komplette Durchdringung in einem vorgelagerten Compilations-Proze&#223;. Die genauere Analyse hat mich dorthin gebracht: ein klassisches &#187;pull-processing&#171; f&#252;hrt n&#228;mlich zu einem chaotischen Suchverhalten und erfordert zumindest dynamische Allokation, besser noch sogar einen Garbage-Collector. Und &#8212; was f&#252;r mich noch viel wichtiger geworden ist &#8212; es verteilt die Entscheidungs-Logik &#252;ber den Ausf&#252;hrungs-Pfad, und zwar in Form von <i>cleveren Tricks. </i>Kaum etwas verachte ich mehr, als einen solchen Programmierstil.
</p>
<p>
Allerdings &#8212; <b>zwei Aspekte</b>&#160;bleiben von diesem Ansatz dennoch <b>erhalten</b>:
</p>
<ul>
<li>
der rekursive depth-first-Aufruf, und damit der Verzicht auf ein vorausgeplantes Daten-Management
</li>
<li>
die <i>Analyse-Richtung</i>&#160;r&#252;ckw&#228;rts vom Ergebnis zu den Vorraussetzungen (wenngleich auch dies bereits im Builder passiert)
</li>
</ul>
</body>
</html></richcontent>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1713739052516" ID="ID_1749970594" MODIFIED="1713739377677" TEXT="polymorphe &#xbb;Nodes&#xab;">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...so im Sinn eines &#187;Node-Editors&#171; &#8212; eine Node die eigentlich ein plug-in ist, und &#8222;alles machen&#8220; kann; das w&#252;rde n&#228;mlich voraussetzen, da&#223; alle Nodes <i>irgendwie miteinander kompatibel </i>sind oder automatisch aneinander angepa&#223;t werden &#8212; das w&#228;re etwas, was wir hier <i>ganz explizit nicht wollen, </i>sondern bereits im Builder abhandeln
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1713740231502" ID="ID_629177110" MODIFIED="1713740548024" TEXT="direkter Model-Bezug">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...der erste Entwurf war viel zu sehr von der Idee einer &#8222;geschickten&#8220; Implementierung gepr&#228;gt; daher war vorgesehen, direkt auf eine &#187;high-level&#171;-Logik durchzugreifen &#8212; im Besonderen auch im Hinblick auf die Automation. Von diesem Ansatz habe ich mich inzwischen komplett gel&#246;st; vielmehr setze ich auf <i>symbolische Repr&#228;sentation, </i>die dann die n&#228;chsten &#220;bersetzungs-Schritte ansteuert, und so schrittweise in eine vollst&#228;ndige Parametrisierung und Konfiguration des Rechenvorgangs m&#252;ndet
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1713740696724" ID="ID_806179742" MODIFIED="1713741161856" TEXT="direkter Umgang mit Data-Buffers">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...im ersten Entwurf dachte ich, da&#223; der Kern der Berechnung aus dem direkten Aufruf von C-Funktionen bestehen mu&#223;, weil dadurch die Berechnung maximal performant wird; daraus ergab sich auch, da&#223; der &#187;pull-call&#171; direkt ein Array von Buffer(pointern) weitergibt. Das hat sich auf mehreren Ebenen als naiv herausgestellt. Zun&#228;chst einmal, die Berechnung soll stets von einem externen plug-in oder einer Library &#252;bernommen werden; daher ist klar, da&#223; jeder Aufruf <i>zwangsl&#228;ufig durch einen Adapter-Layer geht. </i>Demzufolge wird es im &#187;pull-call&#171; stets darum gehen, gewisse Handles oder andere symbolische Repr&#228;sentationen weiterzuleiten, und die <i>vorgeblich besonders performante low-Leveligkeit</i>&#160;ist nichts als Augenwischerei, denn die Laufzeit wird ohnehin <i>in der Berechnungsfunktion</i>&#160;verbracht. Viel wichtiger ist es, <i>explizite Auswertungen zur Laufzeit</i>&#160;zu vermeiden, sofern diese bereits vorneweg f&#252;r ein gesamtes Segment gemacht werden k&#246;nnen.
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
<node CREATED="1713743244876" ID="ID_788939728" MODIFIED="1713743250142" TEXT="Einsch&#xe4;tzung">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1713743251125" ID="ID_1888464433" MODIFIED="1713743458090" TEXT="was ich schon bef&#xfc;rchtet habe &#x2014; sehr detailiert ausimplementiert und doch &#x201e;frei schwebend&#x201c;">
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1713743423876" ID="ID_1769296388" MODIFIED="1713743465725">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
es besteht (weiterhin) ein bedenkliches <b>Henne-oder-Ei-Problem</b>
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1713743468114" ID="ID_1741718774" MODIFIED="1713743494782" TEXT="das hat mich damals (2012) bereits an der weiteren Implemetierung gehindert"/>
<node CREATED="1713743498674" ID="ID_184410399" MODIFIED="1713743520587" TEXT="und es besteht bis heute nahezu unver&#xe4;ndert weiter"/>
<node BACKGROUND_COLOR="#ede064" COLOR="#fa002a" CREATED="1713743525943" ID="ID_640272147" MODIFIED="1713743654579" TEXT="ProcNode &#xd83e;&#xdc32; Invocation &#xd83e;&#xdc32; JobTicket &#xd83e;&#xdc32; Fixture &#xd83e;&#xdc32; ProcNode">
<icon BUILTIN="clanbomber"/>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1713743677951" ID="ID_1878090601" MODIFIED="1713743711574" TEXT="es gibt keinerlei brauchbare Testabdeckung (genau wegen diesem Problem)">
<icon BUILTIN="messagebox_warning"/>
</node>
<node COLOR="#583453" CREATED="1713743739274" ID="ID_1675331897" MODIFIED="1713744114670" TEXT="ich bin damals ein St&#xfc;ck weit dem Template-Metaprogramming verfallen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...weil es so stringent ist und man direkt bei der Compilation eine R&#252;ckmeldung bekommt; aufgrund der fehlenden Au&#223;en-Verankerung habe ich lange gar nicht gemerkt, da&#223; die <i>compiletime vs runtime division</i>&#160; eine H&#252;rde darstellt, die die verlockende Idee praktisch unm&#246;glich macht. Andererseits habe ich hier erstmals die sehr fruchbare Idee des compiletime-Layering angewendet, konnte damals aber nicht richtig damit umgehen. Inzwischen habe ich die M&#246;glichkeiten und Grenzen dieser Idee verstanden und erfolgreich angewandt (f&#252;r die GenNode, das Diff-System, die Event-Log-Suche und den IterExplorer)
</p>
</body>
</html></richcontent>
<icon BUILTIN="smiley-oh"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1713744037866" ID="ID_863347622" MODIFIED="1713744085721" TEXT="ich sollte das Thema komplett neu aufrollen &#x2014; ausgehend vom &#xbb;turnout system&#xab;">
<linktarget COLOR="#483e74" DESTINATION="ID_863347622" ENDARROW="Default" ENDINCLINATION="456;0;" ID="Arrow_ID_1595016691" SOURCE="ID_201859142" STARTARROW="None" STARTINCLINATION="426;67;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1713793648079" ID="ID_907714892" MODIFIED="1713793672085" TEXT="aber vorhandener Code kann weitgehend mitverwendet werden">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1713795084878" ID="ID_900623108" MODIFIED="1713795152331" TEXT="das Buffer-Protocol gilt als gesetzt">
<linktarget COLOR="#3c61b7" DESTINATION="ID_900623108" ENDARROW="Default" ENDINCLINATION="-475;-40;" ID="Arrow_ID_245920004" SOURCE="ID_267762321" STARTARROW="None" STARTINCLINATION="-218;8;"/>
<icon BUILTIN="yes"/>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1713819850506" ID="ID_1750491613" MODIFIED="1713819862771" TEXT="zu kl&#xe4;ren">
<icon BUILTIN="yes"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713819879109" ID="ID_943908122" MODIFIED="1713819899886" TEXT="Entwurf und Aufbau">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1713820093819" ID="ID_1401449333" MODIFIED="1713823888370" TEXT="Zugangsweg">
<icon BUILTIN="forward"/>
<node CREATED="1713820133641" ID="ID_888185703" MODIFIED="1713820154894" TEXT="Gliederung in drei Stufen">
<node CREATED="1713820156058" ID="ID_196721850" MODIFIED="1713820161892" TEXT="Node-Graph bauen"/>
<node CREATED="1713820162707" ID="ID_754976135" MODIFIED="1713820243651" TEXT="Turnout-System anlegen"/>
<node CREATED="1713820261701" ID="ID_308303726" MODIFIED="1713820265885" TEXT="Einzelausf&#xfc;hrung linken"/>
</node>
<node CREATED="1713823582760" ID="ID_857212769" MODIFIED="1713823865318" TEXT="Kl&#xe4;rung: einfach &#x27f6; komplex">
<icon BUILTIN="yes"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823596151" ID="ID_252499492" MODIFIED="1713823821817" TEXT="Node-Grundstruktur">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823635758" ID="ID_899523613" MODIFIED="1713823821818" TEXT="Gundelemente des Aufrufs">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823642113" ID="ID_1687015571" MODIFIED="1713823821818" TEXT="TurnoutSystem als Zentral-Element">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823682795" ID="ID_868323088" MODIFIED="1713823821819" TEXT="Kl&#xe4;ren der Probleme mit den Prototypen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823751762" ID="ID_1428576691" MODIFIED="1713823821819" TEXT="Node-Basisf&#xe4;lle">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823756010" ID="ID_1046868216" MODIFIED="1713823821820" TEXT="einfachst m&#xf6;glicher Generator">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823770168" ID="ID_299121993" MODIFIED="1713823821820" TEXT="herausf&#xfc;hren in Exit-Node">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823762377" ID="ID_1217889312" MODIFIED="1713823821820" TEXT="einfache Processor-Node">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
<node CREATED="1713823918124" ID="ID_1749289662" MODIFIED="1713823922851" TEXT="Testbarkeit">
<node CREATED="1713823928074" ID="ID_1359856614" MODIFIED="1713823939046" TEXT="Node mu&#xdf; direkt konstruierbar sein"/>
<node CREATED="1713823944920" ID="ID_1929417005" MODIFIED="1713823954451" TEXT="Node mu&#xdf; Verschaltungs-API bieten"/>
<node CREATED="1713823999457" ID="ID_1445622002" MODIFIED="1713824007500" TEXT="Steuerbarkeit per TurnoutSystem"/>
<node CREATED="1713824070968" ID="ID_1427325952" MODIFIED="1713824271145" TEXT="Struktur TurnoutSystem ableiten"/>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1713821236750" ID="ID_1655113761" MODIFIED="1713823539175" TEXT="testgetriebener Aufbau">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713821606607" ID="ID_492497884" MODIFIED="1713823536290" TEXT="NodeDevel_test">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1713823362710" ID="ID_66967253" MODIFIED="1713823377315" TEXT="Hilfsmittel zur Entwicklung und zum Aufbau"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1713821694886" ID="ID_1102491970" MODIFIED="1713823534427" TEXT="NodeLinkage_test">
<icon BUILTIN="flag-pink"/>
<node CREATED="1713823379083" ID="ID_673154392" MODIFIED="1713823395389" TEXT="die drei Stufen der Verschaltung"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1713823407007" ID="ID_392149724" MODIFIED="1713823477637" STYLE="bubble" TEXT="&#x25b6; f&#xf6;rdert den Kern des Aufbaus &#x25c0;">
<edge COLOR="#985353"/>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1713821706444" ID="ID_1035135639" MODIFIED="1713823527160" TEXT="NodeBasic_test">
<icon BUILTIN="hourglass"/>
<node CREATED="1713823489509" ID="ID_738439301" MODIFIED="1713823496942" TEXT="idealerweise nebenbei mit anlegen"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1713821728361" ID="ID_1456365802" MODIFIED="1713823527161" TEXT="NodeFactory_test">
<icon BUILTIN="hourglass"/>
<node CREATED="1713823503251" ID="ID_1961332963" MODIFIED="1713823519437" TEXT="m&#xf6;glicherweise einfachsten Fall hier"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713824325760" ID="ID_1661035289" MODIFIED="1713824498751" TEXT="BufferProviderProtocol_test">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1713824328087" ID="ID_1065671274" MODIFIED="1713824335184" TEXT="Standard-Fall fertigstellen"/>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1713824835597" ID="ID_1311484733" MODIFIED="1713825651947" TEXT="Dokumentation">
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#c5aba5" CREATED="1713824849805" ID="ID_261141897" MODIFIED="1713825857023" TEXT="erfolgt im TiddlyWiki">
<arrowlink COLOR="#7881a8" DESTINATION="ID_738696775" ENDARROW="Default" ENDINCLINATION="-1101;-221;" ID="Arrow_ID_475958331" STARTARROW="None" STARTINCLINATION="-1253;151;"/>
<icon BUILTIN="info"/>
</node>
<node CREATED="1713825527837" ID="ID_629287654" MODIFIED="1713825543551" TEXT="Konzept / Protocol umgestalten"/>
<node CREATED="1713825545675" ID="ID_366279400" MODIFIED="1713825552646" TEXT="RenderMechanics anpassen"/>
<node CREATED="1713825555297" ID="ID_886335223" MODIFIED="1713825560834" TEXT="RenderImplDetails aktualisieren"/>
<node CREATED="1713825561360" ID="ID_1766337727" MODIFIED="1713825572283" TEXT="RenderEntities komplett neu gestalten"/>
<node CREATED="1713825583890" ID="ID_768871043" MODIFIED="1713825602591" TEXT="Wiring und FeedManifold"/>
</node>
</node>
<node CREATED="1687302645431" ID="ID_1377069136" MODIFIED="1687302651074" TEXT="Aufruf-Schnittstelle">
<node CREATED="1713819959995" ID="ID_179899941" MODIFIED="1713819974612" TEXT="f&#xfc;r den Modell-Aufbau"/>
<node CREATED="1713819975157" ID="ID_169491541" MODIFIED="1713819978793" TEXT="f&#xfc;r die Job-Planung"/>
<node CREATED="1713819979316" ID="ID_1674780860" MODIFIED="1713820000472" TEXT="f&#xfc;r die Ausf&#xfc;hrung"/>
<node CREATED="1713820001615" ID="ID_1711530409" MODIFIED="1713820004276" TEXT="zum Test"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1687302361438" ID="ID_519176123" MODIFIED="1687302695659" TEXT="Umgang mit der DataSink">
<linktarget COLOR="#7d3f56" DESTINATION="ID_519176123" ENDARROW="Default" ENDINCLINATION="-1337;-138;" ID="Arrow_ID_1252848442" SOURCE="ID_819115625" STARTARROW="None" STARTINCLINATION="-721;60;"/>
<icon BUILTIN="hourglass"/>
@ -118119,6 +118436,7 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1702415678299" ID="ID_1106874700" MODIFIED="1702416416054" TEXT="TiddlyWiki">
<icon BUILTIN="pencil"/>
<node CREATED="1702416367474" ID="ID_954748325" LINK="file:///Lager/heim/devel/lumi/wiki/renderengine.html#PlaybackVerticalSlice%20RenderEngine%20Scheduler%20SchedulerWorker%20SchedulerMemory%20RenderActivity%20Player%20FrameDispatcher%20JobPlanningPipeline%20PlayProcess%20Rendering%20ProcNode%20NodeOperationProtocol" MODIFIED="1702416400953" TEXT="Permalink-1"/>
<node CREATED="1713825795423" ID="ID_1279363046" LINK="file:///Lager/heim/devel/lumi/wiki/renderengine.html#PlaybackVerticalSlice%20RenderEngine%20ProcNode%20RenderProcess%20NodeOperationProtocol%20RenderMechanics%20RenderImplDetails%20WiringDescriptor%20BufferTable%20BufferProvider%20BuffHandle%20BufferMetadata%20OutputManagement%20OutputSlot" MODIFIED="1713825800705" TEXT="Permalink-2"/>
<node COLOR="#338800" CREATED="1702416739656" ID="ID_768711282" MODIFIED="1713568867103" TEXT="Scheduler">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1702416780922" ID="ID_1005887393" MODIFIED="1713568864194" TEXT="RenderActivity">
@ -118177,6 +118495,41 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713825427642" ID="ID_738696775" MODIFIED="1713825857023" TEXT="Invocation">
<linktarget COLOR="#7881a8" DESTINATION="ID_738696775" ENDARROW="Default" ENDINCLINATION="-1101;-221;" ID="Arrow_ID_475958331" SOURCE="ID_261141897" STARTARROW="None" STARTINCLINATION="-1253;151;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1713824862942" ID="ID_1909421670" MODIFIED="1713824877100" TEXT="ProcNode &#x2014; Einstiegsseite"/>
<node CREATED="1713824933924" ID="ID_493944146" MODIFIED="1713824943191" TEXT="RenderProcess &#x2014; &#xdc;bersicht"/>
<node CREATED="1713824953018" ID="ID_276155929" MODIFIED="1713824968468" TEXT="NodeOperationProtocol &#x2014; Konzept"/>
<node CREATED="1713825035029" ID="ID_549287819" MODIFIED="1713825083212" TEXT="RenderMechanics &#x2014; Invocation-Struktur"/>
<node CREATED="1713825093447" ID="ID_1279773508" MODIFIED="1713825107025" TEXT="RenderImplDetails &#x2014; Sammlung von Detailaspekten"/>
<node CREATED="1713825119373" ID="ID_1135448833" MODIFIED="1713825128606" TEXT="WiringDescriptor &#x2014; Verschaltung">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="23" ID="ID_384013577" MODIFIED="1713825443352" TEXT="wird vermutlich umbenannt" VSHIFT="1">
<font NAME="SansSerif" SIZE="10"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1713825180819" ID="ID_1989875443" MODIFIED="1713825185303" TEXT="Einzel-Elemente">
<node CREATED="1713825170661" ID="ID_159721409" MODIFIED="1713825179856" TEXT="BufferTable">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="23" ID="ID_235865414" MODIFIED="1713825443352" TEXT="wird vermutlich umbenannt" VSHIFT="1">
<font NAME="SansSerif" SIZE="10"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1713825226079" ID="ID_1309107373" MODIFIED="1713825459346" TEXT="StateAdapter">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="23" ID="ID_1249060254" MODIFIED="1713825443352" TEXT="wird vermutlich umbenannt" VSHIFT="1">
<font NAME="SansSerif" SIZE="10"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1713825230197" ID="ID_1105758480" MODIFIED="1713825233824" TEXT="StateProxy"/>
<node CREATED="1713825281234" ID="ID_220738428" MODIFIED="1713825282602" TEXT="BufferProvider"/>
<node CREATED="1713825295268" ID="ID_1163491513" MODIFIED="1713825296320" TEXT="BuffHandle"/>
<node CREATED="1713825314633" ID="ID_896282050" MODIFIED="1713825315510" TEXT="BufferMetadata"/>
<node CREATED="1713825372517" ID="ID_483066313" MODIFIED="1713825375024" TEXT="OutputManager"/>
<node CREATED="1713825375559" ID="ID_1937537099" MODIFIED="1713825378379" TEXT="OutputSlot"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1702415745677" ID="ID_889077707" MODIFIED="1702416408821" TEXT="Website">
<icon BUILTIN="hourglass"/>