Invocation: Identify parts relevant for a node builder
The immediate next step is to build some render nodes directly in a test setting, without using any kind of ''node factory.'' Getting ahead with this task requires to identify the constituents to be represented on the first code layer for the reworked code (here ''first layer'' means any part that are ''not'' supplied by generic, templated building blocks). Notably we need to build a descriptor for the `FeedManifold` — which in turn implies we have to decide on some fundamental aspects of handling buffers in the render process. To allow rework of the `ProcNode` connectivity, a lot of presumably obsoleted draft code from 2011 has to be detached, to be able to keep it in-tree for further reference (until the rework and refactoring is settled).
This commit is contained in:
parent
9f233f1e90
commit
717af81986
17 changed files with 911 additions and 47 deletions
218
src/steam/engine/connectivity-obsolete.hpp
Normal file
218
src/steam/engine/connectivity-obsolete.hpp
Normal file
|
|
@ -0,0 +1,218 @@
|
|||
/*
|
||||
PROC-NODE.hpp - Key abstraction of the Render Engine: a Processing Node
|
||||
|
||||
Copyright (C) Lumiera.org
|
||||
2008, 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 connectivity-obsolete.hpp
|
||||
** @deprecated 2024 old variant of render node definition stashed away to keep other obsolete code buildable.
|
||||
**
|
||||
** Actually, there are three different interfaces to consider
|
||||
** - the ProcNode#pull is the invocation interface. It is function-call style
|
||||
** - the builder interface, comprised by the NodeFactory and the WiringFactory.
|
||||
** - the actual processing function is supposed to be a C function and will be
|
||||
** hooked up within a thin wrapper.
|
||||
**
|
||||
** By using the builder interface, concrete node and wiring descriptor classes are created,
|
||||
** based on some templates. These concrete classes form the "glue" to tie the node network
|
||||
** together and contain much of the operation behaviour in a hard wired fashion.
|
||||
**
|
||||
** @todo WIP-WIP-WIP 2024 delete this file!!!!
|
||||
**
|
||||
** @see nodefactory.hpp
|
||||
** @see operationpoint.hpp
|
||||
*/
|
||||
|
||||
#ifndef STEAM_ENGINE_CONNECTIVITY_OBSOLETE_H
|
||||
#define STEAM_ENGINE_CONNECTIVITY_OBSOLETE_H
|
||||
|
||||
#ifdef STEAM_ENGINE_PROC_NODE_H
|
||||
#error "can not include both the old and new Render Node Connectivity scheme"
|
||||
#endif
|
||||
|
||||
#include "lib/error.hpp"
|
||||
#include "steam/common.hpp"
|
||||
#include "steam/asset/proc.hpp"
|
||||
#include "steam/mobject/parameter.hpp"
|
||||
#include "steam/engine/state-closure-obsolete.hpp" /////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "lib/frameid.hpp"
|
||||
#include "lib/ref-array.hpp"
|
||||
|
||||
#include <vector>
|
||||
|
||||
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
|
||||
using std::vector;
|
||||
using lumiera::NodeID;
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
class ProcNode;
|
||||
typedef ProcNode* PNode;
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
class Port
|
||||
{
|
||||
public:
|
||||
virtual ~Port(); ///< this is an interface
|
||||
|
||||
virtual TurnoutSystem enactTurnout() =0;
|
||||
};
|
||||
|
||||
/**
|
||||
* Interface: Description of the input and output ports,
|
||||
* processing function and predecessor nodes for a given ProcNode.
|
||||
*
|
||||
* @todo the design of this part is messy in several respects.
|
||||
* Basically, its left-over from a first prototypical implementation from 2008
|
||||
* As of 1/2012, we're re-shaping that engine interface and invocation with a top-down approach,
|
||||
* starting from the player. Anyhow, you can expect the basic setup to remain as-is: there will
|
||||
* be a ProcNode and a Connectivity descriptor, telling how it's connected to its predecessors,
|
||||
* and defining how the Node is supposed to operate
|
||||
*
|
||||
* @todo WIP-WIP-WIP 2024 Node-Invocation is reworked from ground up for the »Playback Vertical Slice«
|
||||
*/
|
||||
class Connectivity
|
||||
{
|
||||
public: /* === public information record describing the node graph === */
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
uint nrO;
|
||||
uint nrI;
|
||||
|
||||
lib::RefArray<ChannelDescriptor>& out;
|
||||
lib::RefArray<InChanDescriptor>& in;
|
||||
|
||||
typedef asset::Proc::ProcFunc ProcFunc;
|
||||
|
||||
ProcFunc* procFunction;
|
||||
|
||||
NodeID const& nodeID;
|
||||
|
||||
virtual ~Connectivity() {}
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
protected:
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
Connectivity (lib::RefArray<ChannelDescriptor>& o,
|
||||
lib::RefArray<InChanDescriptor>& i,
|
||||
ProcFunc pFunc, NodeID const& nID)
|
||||
: out(o), in(i),
|
||||
procFunction(pFunc),
|
||||
nodeID(nID)
|
||||
{
|
||||
nrO = out.size();
|
||||
nrI = in.size();
|
||||
}
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
/* ==== strategy API for configuring the node operation ==== */
|
||||
|
||||
friend class ProcNode; /////////////////////////////////TODO 1/12 : wouldn't it be better to extract that API into a distinct strategy?
|
||||
|
||||
/** the wiring-dependent part of the node operation.
|
||||
* Includes the creation of a one-way state object on the stack
|
||||
* holding the actual buffer pointers and issuing the recursive pull() calls
|
||||
* @see NodeWiring#callDown default implementation
|
||||
*/
|
||||
virtual BuffHandle
|
||||
callDown (StateClosure_OBSOLETE& currentProcess, uint requiredOutputNr) const =0;
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Key abstraction of the Render Engine: A Data processing Node
|
||||
*
|
||||
* @todo it's not clear as of 9/09 if ProcNode shall be an ABC/Interface
|
||||
* It might be used as ABC (as was the original intention) when implementing
|
||||
* several query/information functions. In that case, the ctor will become protected.
|
||||
* The alternative would be to push down these information-retrieval part into a
|
||||
* configurable element within Connectivity, in which case we even might drop
|
||||
* ProcNode as a frontend entirely.
|
||||
* @todo WIP-WIP-WIP 2024 Node-Invocation is reworked from ground up for the »Playback Vertical Slice«
|
||||
*/
|
||||
class ProcNode
|
||||
: util::NonCopyable
|
||||
{
|
||||
typedef mobject::Parameter<double> Param; //////TODO: just a placeholder for automation as of 6/2008
|
||||
vector<Param> params;
|
||||
|
||||
const Connectivity& wiringConfig_;
|
||||
|
||||
public:
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
ProcNode (Connectivity const& wd)
|
||||
: wiringConfig_(wd)
|
||||
{ }
|
||||
|
||||
virtual ~ProcNode() {}; /////////////////////////TODO: do we still intend to build a hierarchy below ProcNode???
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
|
||||
public:
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
bool isValid() const;
|
||||
|
||||
/** output channel count */
|
||||
uint nrO() { return wiringConfig_.nrO; }
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
|
||||
/** Engine Core operation: render and pull output from this node.
|
||||
* On return, currentProcess will hold onto output buffer(s)
|
||||
* containing the calculated result frames. In case this node
|
||||
* calculates a multichannel output, only one channel can be
|
||||
* retrieved by such a \c pull() call, but you can expect data
|
||||
* of the other channels to be processed and fed to cache.
|
||||
* @param currentProcess the current processing state for
|
||||
* managing buffers and accessing current parameter values
|
||||
* @param requestedOutputNr the output channel requested
|
||||
* (in case this node delivers more than one output channel)
|
||||
* @return handle to the buffer containing the calculated result.
|
||||
*/
|
||||
BuffHandle
|
||||
pull (StateClosure_OBSOLETE& currentProcess, uint requestedOutputNr=0) const
|
||||
{
|
||||
return this->wiringConfig_.callDown (currentProcess, requestedOutputNr);
|
||||
}
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
};
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
inline bool
|
||||
ProcNode::isValid() const
|
||||
{
|
||||
UNIMPLEMENTED ("ProcNode validity self-check");
|
||||
return false; //////////////////////////TODO
|
||||
}
|
||||
|
||||
|
||||
}} // namespace steam::engine
|
||||
#endif /*STEAM_ENGINE_CONNECTIVITY_OBSOLETE_H*/
|
||||
195
src/steam/engine/feed-manifold-obsolete.hpp
Normal file
195
src/steam/engine/feed-manifold-obsolete.hpp
Normal file
|
|
@ -0,0 +1,195 @@
|
|||
/*
|
||||
FEED-MANIFOLD.hpp - data feed connection system for render nodes
|
||||
|
||||
Copyright (C) Lumiera.org
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
2023, 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 feed-manifold-obsolete.hpp
|
||||
** @todo staled since 2009, picked up in 2024 in an attempt to finish the node invocation.
|
||||
** deprecated 2024 this file is a dead-end! It is retained in tree to keep other obsolete code buildable
|
||||
** @see nodeinvocation.hpp
|
||||
*/
|
||||
|
||||
|
||||
#ifndef ENGINE_FEED_MANIFOLD_OBSOLETE_H
|
||||
#define ENGINE_FEED_MANIFOLD_OBSOLETE_H
|
||||
|
||||
|
||||
#include "lib/error.hpp"
|
||||
#include "lib/nocopy.hpp"
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO this is a dead end
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
|
||||
#include <vector>
|
||||
#include <utility>
|
||||
|
||||
|
||||
////////////////////////////////TICKET #826 will be reworked alltogether
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
|
||||
using std::pair;
|
||||
using std::vector;
|
||||
|
||||
|
||||
/**
|
||||
* Obsolete, to be rewritten /////TICKET #826
|
||||
*
|
||||
* Tables of buffer handles and corresponding dereferenced buffer pointers.
|
||||
* Used within the invocation of a processing node to calculate data.
|
||||
* The tables are further differentiated into input data buffers and output
|
||||
* data buffers. The tables are supposed to be implemented as bare "C" arrays,
|
||||
* thus the array of real buffer pointers can be fed directly to the
|
||||
* processing function of the respective node.
|
||||
*
|
||||
* @todo this whole design is a first attempt and rather clumsy. It should be reworked
|
||||
* to use a single contiguous memory area and just layer the object structure on top
|
||||
* (by using placement new). Yet the idea of an stack-like organisation should be retained
|
||||
*/
|
||||
struct FeedManifold ///////////////////////////////////OOO rename into FeedManifold
|
||||
{
|
||||
typedef BuffHandle * PHa;
|
||||
typedef BuffHandle::PBuff * PBu;
|
||||
typedef pair<PHa const,PBu const> Chunk;
|
||||
|
||||
PHa outHandle;
|
||||
PHa inHandle;
|
||||
PBu outBuff;
|
||||
PBu inBuff;
|
||||
};
|
||||
|
||||
class BufferDescriptor;
|
||||
|
||||
/** Obsolete, to be rewritten /////TICKET #826 */
|
||||
class BuffTableStorage
|
||||
{
|
||||
/////////////////////////////////////////////////////////////////////////TICKET #826 need to be reworked entirely
|
||||
/** just a placeholder to decouple the existing code
|
||||
* from the reworked BuffHandle logic. The existing
|
||||
* code in turn will be reworked rather fundamentally
|
||||
*/
|
||||
struct BuffHaXXXX
|
||||
: BuffHandle
|
||||
{
|
||||
BuffHaXXXX() : BuffHandle(just_satisfy_the_compiler()) { /* wont work ever */ }
|
||||
static BufferDescriptor const&
|
||||
just_satisfy_the_compiler() { }
|
||||
};
|
||||
|
||||
////////////////////////////////////TICKET #825 should be backed by mpool and integrated with node invocation
|
||||
vector<BuffHaXXXX> hTab_;
|
||||
vector<BuffHandle::PBuff> pTab_;
|
||||
size_t level_;
|
||||
|
||||
public:
|
||||
BuffTableStorage (const size_t maxSiz)
|
||||
: hTab_(maxSiz),
|
||||
pTab_(maxSiz),
|
||||
level_(0)
|
||||
{ }
|
||||
|
||||
~BuffTableStorage() { ASSERT (0==level_, "buffer management logic broken."); }
|
||||
|
||||
protected:
|
||||
|
||||
friend class BuffTableChunk;
|
||||
|
||||
/** allocate the given number of slots
|
||||
* starting at current level to be used
|
||||
* by the newly created BuffTableChunk
|
||||
*/
|
||||
FeedManifold::Chunk
|
||||
claim (uint slots)
|
||||
{
|
||||
ASSERT (pTab_.size() == hTab_.size());
|
||||
REQUIRE (level_+slots <= hTab_.size());
|
||||
|
||||
size_t prev_level (level_);
|
||||
level_ += slots;
|
||||
return std::make_pair (&hTab_[prev_level],
|
||||
&pTab_[prev_level]);
|
||||
}
|
||||
|
||||
void
|
||||
release (uint slots)
|
||||
{
|
||||
ASSERT (slots <= level_);
|
||||
REQUIRE (level_ <= hTab_.size());
|
||||
REQUIRE (level_ <= pTab_.size());
|
||||
|
||||
level_ -= slots;
|
||||
}
|
||||
|
||||
bool
|
||||
level_check (FeedManifold::Chunk& prev_level)
|
||||
{
|
||||
return prev_level.first == &hTab_[level_]
|
||||
&& prev_level.second == &pTab_[level_];
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
/** Obsolete, to be rewritten /////TICKET #826
|
||||
* to be allocated on the stack while evaluating a ProcNode#pull() call.
|
||||
* The "current" State (StateProxy) maintains a BuffTableStorage (=pool),
|
||||
* which can be used to crate such chunks. The claiming and releasing of
|
||||
* slots in the BuffTableStorage is automatically tied to BuffTableChunk
|
||||
* object's lifecycle.
|
||||
*/
|
||||
class BuffTableChunk
|
||||
: public FeedManifold,
|
||||
util::NonCopyable
|
||||
{
|
||||
const uint siz_;
|
||||
FeedManifold::Chunk tab_;
|
||||
BuffTableStorage& sto_;
|
||||
|
||||
public:
|
||||
BuffTableChunk (Connectivity const& wd, BuffTableStorage& storage)
|
||||
: siz_(wd.nrI + wd.nrO),
|
||||
tab_(storage.claim (siz_)),
|
||||
sto_(storage)
|
||||
{
|
||||
const uint nrO(wd.nrO);
|
||||
|
||||
// Setup the publicly visible table locations
|
||||
this->outHandle = &tab_.first[ 0 ];
|
||||
this->inHandle = &tab_.first[nrO];
|
||||
this->outBuff = &tab_.second[ 0 ];
|
||||
this->inBuff = &tab_.second[nrO];
|
||||
}
|
||||
|
||||
~BuffTableChunk ()
|
||||
{
|
||||
sto_.release (siz_);
|
||||
ASSERT ( sto_.level_check (tab_),
|
||||
"buffer management logic broken.");
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
}} // namespace steam::engine
|
||||
#endif /*ENGINE_FEED_MANIFOLD_OBSOLETE_H*/
|
||||
|
|
@ -65,7 +65,7 @@ namespace engine {
|
|||
* to use a single contiguous memory area and just layer the object structure on top
|
||||
* (by using placement new). Yet the idea of an stack-like organisation should be retained
|
||||
*/
|
||||
struct FeedManifold ///////////////////////////////////OOO rename into FeedManifold
|
||||
struct FeedManifold
|
||||
{
|
||||
typedef BuffHandle * PHa;
|
||||
typedef BuffHandle::PBuff * PBu;
|
||||
|
|
@ -77,6 +77,7 @@ namespace engine {
|
|||
PBu inBuff;
|
||||
};
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : presumably obsolete
|
||||
class BufferDescriptor;
|
||||
|
||||
/** Obsolete, to be rewritten /////TICKET #826 */
|
||||
|
|
@ -185,7 +186,7 @@ namespace engine {
|
|||
"buffer management logic broken.");
|
||||
}
|
||||
};
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : (End)presumably obsolete
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@
|
|||
#include "steam/mobject/session/effect.hpp"
|
||||
#include "lib/allocation-cluster.hpp"
|
||||
|
||||
#include "steam/engine/nodewiring.hpp"
|
||||
//#include "steam/engine/nodewiring-obsolete.hpp"
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
|
|
@ -62,12 +62,15 @@ namespace engine {
|
|||
PNode
|
||||
NodeFactory::operator() (Placement<Effect> const& effect, WiringSituation& intendedWiring)
|
||||
{
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
intendedWiring.resolveProcessor(effect->getProcAsset());
|
||||
Connectivity& wiring = wiringFac_(intendedWiring);
|
||||
|
||||
ProcNode& newNode = alloc_.create<ProcNode> (wiring);
|
||||
ENSURE (newNode.isValid());
|
||||
return &newNode;
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
UNIMPLEMENTED ("Node Factory for reworked Render Node Connectivity");
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@
|
|||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/mobject/placement.hpp"
|
||||
#include "steam/engine/nodewiring.hpp"
|
||||
//#include "steam/engine/nodewiring-obsolete.hpp" /////////////////////////////////////////////////////////TICKET #1367 : Adapt to rework of Node Invocation
|
||||
|
||||
|
||||
////////////////////////////////////TODO: make inclusions / forward definitions a bit more orthogonal....
|
||||
|
|
@ -72,12 +72,16 @@ namespace engine {
|
|||
class NodeFactory
|
||||
{
|
||||
AllocationCluster& alloc_;
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
WiringFactory wiringFac_;
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
public:
|
||||
NodeFactory (AllocationCluster& a)
|
||||
: alloc_(a)
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
, wiringFac_(alloc_)
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
{ }
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,8 @@
|
|||
#define ENGINE_NODE_WIRING_BUILDER_H
|
||||
|
||||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" //////////////////////////////////////////////////////////////////TICKET #1367 : switch to new Node Invocation scheme
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "lib/ref-array.hpp"
|
||||
#include "lib/util-foreach.hpp"
|
||||
#include "lib/nocopy.hpp"
|
||||
|
|
@ -183,7 +184,34 @@ namespace engine {
|
|||
}
|
||||
|
||||
};
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
class NodeWiringBuilder
|
||||
: util::MoveOnly
|
||||
{
|
||||
public:
|
||||
|
||||
/****************************************************//**
|
||||
* Terminal: complete the Connectivity defined thus far.
|
||||
*/
|
||||
// Connectivity
|
||||
void* /////////////////////////////////////////////////OOO Connectivity no longer needs to be abstract
|
||||
build()
|
||||
{
|
||||
UNIMPLEMENTED("Node-Connectivity Setup");
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* Entrance point for building node Connectivity
|
||||
*/
|
||||
template<class ONT>
|
||||
auto
|
||||
buildPatternFor()
|
||||
{
|
||||
UNIMPLEMENTED("instantiate Domain Ontology Facade and outfit the NodeWiringBuilder");
|
||||
}
|
||||
|
||||
|
||||
}} // namespace steam::engine
|
||||
|
|
|
|||
|
|
@ -55,10 +55,11 @@
|
|||
#define ENGINE_NODEINVOCATION_H
|
||||
|
||||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO clarify if required further on
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "steam/engine/state-closure-obsolete.hpp"
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp"
|
||||
#include "steam/engine/feed-manifold-obsolete.hpp"
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -57,11 +57,12 @@
|
|||
#define ENGINE_NODEOPERATION_H
|
||||
|
||||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO clarify if required further on
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "steam/engine/state-closure-obsolete.hpp"
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
#include "steam/engine/nodeinvocation.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp"
|
||||
#include "steam/engine/feed-manifold-obsolete.hpp"
|
||||
|
||||
#include "lib/meta/util.hpp"
|
||||
#include "lib/meta/configflags.hpp"
|
||||
|
|
|
|||
|
|
@ -24,16 +24,22 @@
|
|||
/** @file nodewiring.hpp
|
||||
** Mechanism to wire ProcNode instances for a render network
|
||||
** @todo unfinished draft from 2009 regarding the render process
|
||||
** @deprecated 2024 this header will likely be obsoleted
|
||||
** @see node-wiring-builder.hpp for the rewritten node-builder
|
||||
*/
|
||||
|
||||
|
||||
#ifndef ENGINE_NODEWIRING_H
|
||||
#define ENGINE_NODEWIRING_H
|
||||
#ifndef ENGINE_NODEWIRING_OBSOLETE_H
|
||||
#define ENGINE_NODEWIRING_OBSOLETE_H
|
||||
|
||||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO clarify if required further on
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "steam/engine/node-wiring-builder.hpp"
|
||||
#include "lib/allocation-cluster.hpp"
|
||||
#include "lib/ref-array.hpp"
|
||||
#include "lib/util-foreach.hpp"
|
||||
#include "lib/nocopy.hpp"
|
||||
|
||||
#include <memory>
|
||||
|
||||
|
|
@ -27,8 +27,9 @@
|
|||
*/
|
||||
|
||||
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/nodewiring.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO clarify if required further on
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "steam/engine/nodewiring-obsolete.hpp"
|
||||
#include "steam/engine/nodeoperation.hpp"
|
||||
#include "steam/engine/nodewiring-config.hpp"
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,8 @@
|
|||
#include "steam/common.hpp"
|
||||
#include "steam/asset/proc.hpp"
|
||||
#include "steam/mobject/parameter.hpp"
|
||||
#include "steam/engine/state-closure-obsolete.hpp" /////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
//#include "steam/engine/state-closure-obsolete.hpp" ///////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
#include "steam/engine/state-closure.hpp" /////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "lib/frameid.hpp"
|
||||
|
|
@ -132,8 +133,10 @@ namespace engine {
|
|||
* holding the actual buffer pointers and issuing the recursive pull() calls
|
||||
* @see NodeWiring#callDown default implementation
|
||||
*/
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
virtual BuffHandle
|
||||
callDown (StateClosure_OBSOLETE& currentProcess, uint requiredOutputNr) const =0;
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
};
|
||||
|
|
@ -191,11 +194,13 @@ namespace engine {
|
|||
* (in case this node delivers more than one output channel)
|
||||
* @return handle to the buffer containing the calculated result.
|
||||
*/
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
BuffHandle
|
||||
pull (StateClosure_OBSOLETE& currentProcess, uint requestedOutputNr=0) const
|
||||
{
|
||||
return this->wiringConfig_.callDown (currentProcess, requestedOutputNr);
|
||||
}
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
};
|
||||
|
|
|
|||
|
|
@ -37,7 +37,8 @@
|
|||
|
||||
|
||||
//#include "steam/engine/state-closure.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
//#include "steam/engine/proc-node.hpp" ///////////////////////////////TODO clarify if required further on
|
||||
#include "steam/engine/connectivity-obsolete.hpp"
|
||||
#include "steam/engine/buffhandle.hpp"
|
||||
//#include "steam/engine/bufftable-obsolete.hpp"
|
||||
|
||||
|
|
|
|||
|
|
@ -77,8 +77,10 @@ namespace test {
|
|||
virtual uint getNrI() const { return ii; }
|
||||
virtual uint getNrO() const { return oo; }
|
||||
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
virtual BuffHandle callDown (StateClosure_OBSOLETE&, uint) const
|
||||
{ throw lumiera::Error("not intended to be called"); }
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ namespace test {
|
|||
setupDependentJob()
|
||||
{
|
||||
MockDispatcher dispatcher{MakeRec() // »master job« for each frame
|
||||
.attrib("runtime", Duration{Time{30,0}})
|
||||
.attrib("runtime", Duration{Time{30,0}})
|
||||
.scope(MakeRec() // a »prerequisite job« on which the »master job« depends
|
||||
.attrib("runtime", Duration{Time{50,0}})
|
||||
.genNode())
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
|
||||
#include "lib/test/run.hpp"
|
||||
#include "steam/engine/node-factory.hpp"
|
||||
#include "steam/engine/nodewiring.hpp"
|
||||
//#include "steam/engine/nodewiring-obsolete.hpp" /////////////////////////////////////////////////////TICKET #1367 : sort out dependencies for reworked Node Invocation
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "steam/engine/channel-descriptor.hpp"
|
||||
#include "steam/mobject/session/effect.hpp"
|
||||
|
|
@ -87,11 +87,13 @@ namespace test {
|
|||
ProcNode * testSource; ///////////TODO: how to fabricate a test Source-Node????
|
||||
|
||||
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
WiringSituation setup(testSource);
|
||||
|
||||
PEffect pEffect = createTestEffectMObject();
|
||||
ProcNode* pNode = nodeFab (pEffect, setup);
|
||||
CHECK (pNode);
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
TestContext simulatedInvocation;
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
|
|
|
|||
|
|
@ -1250,7 +1250,7 @@ Beyond that, it can be necessary to associate at least a state flag with //indiv
|
|||
__Note__: while the API to access this service is uniform, conceptually there is a difference between just using the (shared) type information and associating individual metadata, like the buffer state. Type-~IDs, once allocated, will never be discarded (within the lifetime of an Lumiera application instance -- buffer associations aren't persistent). To the contrary, individual metadata //will be discarded,// when releasing the corresponding buffer. According to the ''prototype pattern'', individual metadata is treated as a one-way-off specialisation.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="BufferProvider" modifier="Ichthyostega" created="201107082330" modified="201111192223" tags="Rendering spec draft">
|
||||
<div title="BufferProvider" modifier="Ichthyostega" created="201107082330" modified="202406241656" tags="Rendering spec draft" changecount="3">
|
||||
<pre>It turns out that -- throughout the render engine implementation -- we never need direct access to the buffers holding actual media data. Buffers are just some entity to be //managed,// i.e. "allocated", "locked" and "released"; the //actual meaning of these operations can be left to the implementation.// The code within the render engine just pushes around ''smart-prt like handles''. These [[buffer handles|BuffHandle]] act as a front-end, being created by and linked to a buffer provider implementation. There is no need to manage the lifecycle of buffers automatically, because the use of buffers is embedded into the render calculation cycle, which follows a rather strict protocol anyway. Relying on the [[capabilities of the scheduler|SchedulerRequirements]], the sequence of individual jobs in the engine ensures...
|
||||
* that the availability of a buffer was ensured prior to planning a job ("buffer allocation")
|
||||
* that a buffer handle was obtained ("locked") prior to any operation requiring a buffer
|
||||
|
|
@ -1264,6 +1264,8 @@ While BufferProvider is an interface meant to be backed by various different kin
|
|||
:this operation actually makes a buffer available for a specific client and returns a [[buffer handle|BuffHandle]]. The corresponding buffer is marked as used and can't be locked again unless released. If necessary, at that point the BufferProvider might allocate memory to accommodate (especially when the buffers weren't announced beforehand). The locking may fail and raise an exception. You may expect failure to be unlikely when buffers have been //announced beforehand.// To support additional sanity checks, the client may provide a token-ID with the lock-operation. This token may be retrieved later and it may be used to ensure the buffer is actually locked for //this token.//
|
||||
;attaching
|
||||
:optionally the client may attach an object to a locked buffer. This object is placement-constructed into the buffer and will be destroyed automatically when releasing the buffer. Alternatively, the client may provide a pair of constructor- / destructor-functors, to be invoked in a similar way. This allows e.g. to install descriptor structures within the buffer, as required by an external library.
|
||||
;emitting
|
||||
:the client //may optionally mark a state transition// -- whose precise meaning remains implicit and implementation dependent. From the client's perspective, emitting and releasing may seem equivalent, since the buffer should not be touched after that point. However, conceivably there are usages where it matters for //the consumer// to be sure an expected result was actually achieved, since the producer may well acquire the buffer and then fail to complete the required work, prompting some clean-up safety mechanism to merely release the resources.
|
||||
;releasing
|
||||
:buffers need to be released explicitly by the client code. This renders the corresponding BuffHandle invalid, (optionally) invokes a destructor function of an attached object and maybe reclaims the buffer memory
|
||||
|
||||
|
|
@ -5104,9 +5106,9 @@ Thus the mapping is a copyable value object, using an associative array. It may
|
|||
First and foremost, mapping can be seen as a //functional abstraction.// As it's used at implementation level, encapsulation of detail types in't the primary concern, so it's a candidate for generic programming: For each of those use cases outlined above, a distinct mapping type is created by instantiating the {{{OutputMapping<DEF>}}} template with a specifically tailored definition context ({{{DEF}}}), which takes on the role of a strategy. Individual instances of this concrete mapping type may be default created and copied freely. This instantiation process includes picking up the concrete result type and building a functor object for resolving on the fly. Thus, in the way typical for generic programming, the more involved special details are moved out of sight, while being still in scope for the purpose of inlining. But there //is// a concern better to be encapsulated and concealed at the usage site, namely accessing the rules system. Thus mapping leads itself to the frequently used implementation pattern where there is a generic frontend as header, calling into opaque functions embedded within a separate compilation unit.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="OutputSlot" modifier="Ichthyostega" created="201106162339" modified="202404290107" tags="def Concepts Player spec img" changecount="3">
|
||||
<div title="OutputSlot" modifier="Ichthyostega" created="201106162339" modified="202406241625" tags="def Concepts Player spec img" changecount="6">
|
||||
<pre>Within the Lumiera player and output subsystem, actually sending data to an external output requires to allocate an ''output slot''
|
||||
This is the central metaphor for the organisation of actual (system level) outputs; using this concept allows to separate and abstract the data calculation and the organisation of playback and rendering from the specifics of the actual output sink. Actual output possibilities (video in GUI window, video fullscreen, sound, Jack, rendering to file) can be added and removed dynamically from various components (Vault, Stage), all using the same resolution and mapping mechanisms (&rarr; OutputManagement)
|
||||
This is the central metaphor for the organisation of actual (system level) outputs; using this concept allows to separate and abstract the data calculation and the organisation of playback and rendering from the specifics of the actual output sink. Actual output possibilities (video in GUI window, video fullscreen, using a beamer, sound, Jack, rendering to file) can be added and removed dynamically from various components (Vault, Stage), all using the same resolution and mapping mechanisms (&rarr; OutputManagement)
|
||||
|
||||
!Properties of an output slot
|
||||
Each OutputSlot is an unique and distinguishable entity. It corresponds explicitly to an external output, or a group of such outputs (e.g. left and right soundcard output channels), or an output file or similar capability accepting media content. First off, an output slot needs to be provided, configured and registered, using an implementation for the kind of media data to be output (sound, video) and the special circumstances of the output capability (render a file, display video in a GUI widget, send video to a full screen display, establish a Jack port, just use some kind of "sound out"). An output slot is always limited to a single kind of media, and to a single connection unit, but this connection may still be comprised of multiple channels (stereoscopic video, multichannel sound).
|
||||
|
|
@ -5125,7 +5127,7 @@ Besides the sink handles, allocation of an output slot defines some timing const
|
|||
The assumption is for the client to have elaborate timing capabilities at his disposal. More specifically, the client is assumed to be a job running within the engine scheduler and thus can be configured to run //after// another job has finished, and to run within certain time limits. Thus the client is able to provide a //current nominal time// -- which is suitably close to the actual wall clock time. This enables the output slot implementation to work out from this time specification if the call is timely or overdue -- and react accordingly.
|
||||
|
||||
!!!output modes
|
||||
some concrete output connections and drivers embody a specific operation mode (e.g. sample rate or number of channels). The decision and setup of these operational configuration is initiated together with the [[resolution|OutputMapping]] of an OutputDesignation within the OutputManager, finally leading to an output slot (reference), which can be assumed to be suitably configured, before the client allocates this slot for active use. Moreover, an individual output sink (corresponding to a single channel) may just remain unused -- until there is an {{{emit()}}} call and successful data handover, this channel will just feature silence or remain black. (More flexible system, e.g. Jack, allow to generate an arbitrary number of output pins -- Lumiera will support this by allowing to set up additional output slots and attach this information to the current session &rarr; SessionConfigurationAttachment)
|
||||
some concrete output connections and drivers embody a specific operation mode (e.g. sample rate or number of channels). The decision and setup of these operational configuration is initiated together with the [[resolution|OutputMapping]] of an OutputDesignation within the OutputManager, finally leading to an output slot (reference), which can be assumed to be suitably configured, before the client allocates this slot for active use. Moreover, an individual output sink (corresponding to a single channel) may just remain unused -- until there is an {{{emit()}}} call and successful data handover, this channel will just feature silence or remain black. (There are some output systems with additional flexibility, e.g. ~Jack-Audio, that allow to generate an arbitrary number of output pins -- Lumiera will support this by allowing to set up additional output slots and attach this information to the current session &rarr; SessionConfigurationAttachment)
|
||||
|
||||
!!!Lifecycle and storage
|
||||
The concrete OutputSlot implementation is owned and managed by the facility actually providing the output possibility in question. For example, the GUI provides viewer widgets, while some sound output backend provides sound ports. The associated OutputSlot implementation object is required to stay alive as long as it's registered with some OutputManager. It needs to be de-registered explicitly prior to destruction -- and this deregistration may block until all clients using this slot did terminate. Beyond that, an output slot implementation is expected to handle all kinds of failures gracefully -- preferably just emitting a signal (callback functor).
|
||||
|
|
|
|||
|
|
@ -68347,6 +68347,7 @@
|
|||
</node>
|
||||
<node CREATED="1482524498822" ID="ID_431883229" MODIFIED="1557498707236" TEXT="Datenstrom">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1680567302856" ID="ID_599503027" MODIFIED="1680567686765" TEXT="Output-Management">
|
||||
<linktarget COLOR="#890814" DESTINATION="ID_599503027" ENDARROW="Default" ENDINCLINATION="-447;649;" ID="Arrow_ID_1542547570" SOURCE="ID_1793577189" STARTARROW="None" STARTINCLINATION="-1299;-27;"/>
|
||||
<icon BUILTIN="stop"/>
|
||||
<node CREATED="1680567318639" ID="ID_1726615423" MODIFIED="1680567321766" TEXT="Verdrahtung">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1680567648993" ID="ID_1721405470" MODIFIED="1680567663524" TEXT="Grundkonzept">
|
||||
|
|
@ -79951,7 +79952,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1686839595101" ID="ID_820009401" MODIFIED="1686839603205" TEXT="Start Play-Prozeß">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1686839605000" ID="ID_1798920925" MODIFIED="1686839608748" TEXT="in CalcStram">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1686839605000" ID="ID_1798920925" MODIFIED="1686839608748" TEXT="in CalcStream">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1686839648763" ID="ID_1362535653" MODIFIED="1686839653608" TEXT="Einbindung Dispatcher">
|
||||
|
|
@ -80040,6 +80041,18 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1680563536655" ID="ID_1180632123" MODIFIED="1680565151548" TEXT="Fixture: einfacher Clip">
|
||||
<linktarget COLOR="#f6e1c2" DESTINATION="ID_1180632123" ENDARROW="Default" ENDINCLINATION="-985;-61;" ID="Arrow_ID_1052251062" SOURCE="ID_1704865245" STARTARROW="None" STARTINCLINATION="-2243;270;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1719267418558" ID="ID_1746035700" MODIFIED="1719267571677" TEXT="soll hier dem Ergebnis eines echten Builder-Laufes vorgreifen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...für den »Playback Vertical Slice« wird eine Fixture fabriziert, wie sie <i>vermutlich später mal</i> vom Builder produziert werden wird (wenn es ihn dann endlich mal gibt) — tatsächlich sehe ich das als ersten prototypischen Entwurf, den ich hier nebenbei aus einer bottom-up-Bewegung gewinnen kann
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1681742004652" ID="ID_806189817" MODIFIED="1681742017755" TEXT="Addressierung ModelPort / ExitNode">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
|
|
@ -80429,8 +80442,21 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1714329007283" ID="ID_1710787321" MODIFIED="1714329013657" TEXT="hat ein RenderDrive"/>
|
||||
<node CREATED="1714329024327" ID="ID_1073111908" MODIFIED="1719267945559" TEXT="ein Frame-Job liefert einen Datenframe">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
beachte: dieser »eine Frame« kann durchaus noch inhärent strukturiert sein, beispielsweise mehrere <i>Planes</i> für ein planares Format enthalten oder ein<i> Interleaved-Zyklus</i> von Einzelframes für zusammengehörige Kanäle sein — entscheidend ist, daß dieses Datenelement jeweils<i> als EInheit </i>verwendet und zusammen produziert oder konsumiert wird.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1714329014208" ID="ID_1766738306" MODIFIED="1714329023547" TEXT="dies erzeugt eine Folge von Frame-Jobs"/>
|
||||
<node CREATED="1714329024327" ID="ID_1073111908" MODIFIED="1714329037883" TEXT="ein Frame-Job liefert einen Datenframe"/>
|
||||
<node CREATED="1719267709323" ID="ID_1324726117" MODIFIED="1719267747754" TEXT="»Kanal« bedeutet hier: gemeinsame Datensequenz"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1714269278696" ID="ID_697852023" MODIFIED="1714780242820" TEXT="Verschaltung und Verwendung von Exit-Nodes">
|
||||
|
|
@ -80979,6 +81005,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
</node>
|
||||
<node CREATED="1714870821093" ID="ID_1386001047" MODIFIED="1714870851226" TEXT="OutputBuffer können auf verschiedene Weise zur Verfügung stehen">
|
||||
<node CREATED="1714870852482" ID="ID_718633316" MODIFIED="1714870873555" TEXT="eigens neu alloziert"/>
|
||||
<node CREATED="1714870882693" ID="ID_100322536" MODIFIED="1714870896124" TEXT="im Rahmen eines Belegungs-Schemas"/>
|
||||
<node CREATED="1714870897619" ID="ID_1856124620" MODIFIED="1714870915868" TEXT="extern eingebunden">
|
||||
<node CREATED="1714871833271" ID="ID_999553665" MODIFIED="1714871837441" TEXT="DataSink"/>
|
||||
<node CREATED="1714871837918" ID="ID_585862150" MODIFIED="1714871839753" TEXT="Cache"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1714872052697" ID="ID_1334568846" MODIFIED="1714872067440" TEXT="Node greift über die State-Abstraktion darauf zu"/>
|
||||
<node CREATED="1714870669482" ID="ID_1877886821" MODIFIED="1714870815999" TEXT="das sind Konzepte auf verschiedenen Ebenen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -80993,17 +81028,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#494b7a" DESTINATION="ID_617181865" ENDARROW="Default" ENDINCLINATION="-882;-55;" ID="Arrow_ID_987434698" STARTARROW="None" STARTINCLINATION="-1297;72;"/>
|
||||
<arrowlink COLOR="#533f4c" DESTINATION="ID_1133348458" ENDARROW="Default" ENDINCLINATION="107;-878;" ID="Arrow_ID_208652263" STARTARROW="None" STARTINCLINATION="1479;81;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1714870821093" ID="ID_1386001047" MODIFIED="1714870851226" TEXT="OutputBuffer können auf verschiedene Weise zur Verfügung stehen">
|
||||
<node CREATED="1714870852482" ID="ID_718633316" MODIFIED="1714870873555" TEXT="eigens neu alloziert"/>
|
||||
<node CREATED="1714870882693" ID="ID_100322536" MODIFIED="1714870896124" TEXT="im Rahmen eines Belegungs-Schemas"/>
|
||||
<node CREATED="1714870897619" ID="ID_1856124620" MODIFIED="1714870915868" TEXT="extern eingebunden">
|
||||
<node CREATED="1714871833271" ID="ID_999553665" MODIFIED="1714871837441" TEXT="DataSink"/>
|
||||
<node CREATED="1714871837918" ID="ID_585862150" MODIFIED="1714871839753" TEXT="Cache"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1714872052697" ID="ID_1334568846" MODIFIED="1714872067440" TEXT="Node greift über die State-Abstraktion darauf zu"/>
|
||||
</node>
|
||||
<node CREATED="1714908860345" ID="ID_1143590616" MODIFIED="1714908890326">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -81042,7 +81070,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
In diese Kategorie fallen alle Verarbeitungsschritte, die sich <i>nicht</i>  auf komplett isolierte Primitiv-Operationen auf Einzelkanälen faktorisieren lassen. Beispiel wäre ein Resonanz- oder Reflexionsvorgang in einem Schallfeld, oder eine Überblende- oder Overlay-Operation mit mehreren Masken-Ebenen, die neben dem Basis-Farbwert sowohl Transparenz alsauch Luminanz umfaßt (also das Problem, das pre-multiplied Alpha nicht wirklich lösen kann).
|
||||
In diese Kategorie fallen alle Verarbeitungsschritte, die sich <i>nicht</i> auf komplett isolierte Primitiv-Operationen auf Einzelkanälen faktorisieren lassen. Beispiel wäre ein Resonanz- oder Reflexionsvorgang in einem Schallfeld, oder eine Überblende- oder Overlay-Operation mit mehreren Masken-Ebenen, die neben dem Basis-Farbwert sowohl Transparenz alsauch Luminanz umfaßt (also das Problem, das pre-multiplied Alpha nicht wirklich lösen kann).
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -81309,8 +81337,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1715038460764" ID="ID_739280365" MODIFIED="1715038466834" TEXT="das API ist eigentlich eine Builder"/>
|
||||
<node CREATED="1715038467369" ID="ID_786662983" MODIFIED="1715038479263" TEXT="möglicherweise habe ich hier zwei Ebenen vermischt"/>
|
||||
<node CREATED="1715038460764" ID="ID_739280365" MODIFIED="1719187361719" TEXT="das API deutet auf Gebrauch als Builder hin"/>
|
||||
<node CREATED="1715038467369" ID="ID_786662983" MODIFIED="1715038479263" TEXT="möglicherweise habe ich hier zwei Ebenen vermischt">
|
||||
<node CREATED="1719187815967" ID="ID_715397243" MODIFIED="1719187824665" TEXT="die tatsächliche Verschaltung der Nodes"/>
|
||||
<node CREATED="1719187838783" ID="ID_6577539" MODIFIED="1719187858357" TEXT="das Festlegen gewünschter Eigenschaften für den Node-Graphen"/>
|
||||
</node>
|
||||
<node CREATED="1715038480514" ID="ID_807793427" MODIFIED="1715038523263" TEXT="die Unterscheidung von Martin Fowler: command-&-control vs. DSL">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -81331,12 +81362,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1715038681327" ID="ID_261439848" MODIFIED="1715177341009" TEXT="es führt aber zu einem gefährlich verkoppelten monolithischen System">
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
</node>
|
||||
<node CREATED="1715038717490" ID="ID_226214844" MODIFIED="1715038783206" TEXT="und war konkret auch der Grund, warum ich damals steckenblieb">
|
||||
<node CREATED="1715038717490" ID="ID_226214844" MODIFIED="1719188078354" TEXT="und war konkret auch der Anlaß, an dem ich damals steckenblieb">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn das high-Level-Model kann man genau deshalb im Kern (noch) nicht definieren, weil der Builder und das low-Level-Model fehlt
|
||||
denn das high-Level-Model kann man genau deshalb im Kern (noch) nicht definieren, weil der Builder und das low-Level-Model fehlt — der eigentliche Grund dahinter aber war, daß ich den Sachverhalt noch nicht so weit verstanden hatte, daß ich für einen eignen Entwurf bereit war...
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -81362,6 +81393,37 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719188170735" ID="ID_295398317" MODIFIED="1719191022326" TEXT="hier verliert sich die Spur....">
|
||||
<arrowlink COLOR="#ff004b" DESTINATION="ID_1276741051" ENDARROW="Default" ENDINCLINATION="460;0;" ID="Arrow_ID_1977387211" STARTARROW="None" STARTINCLINATION="-52;188;"/>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
<node CREATED="1719188181421" ID="ID_306677012" MODIFIED="1719188208600" TEXT="dazu müßte es als Vorraussetzung bereits ein abstraktes Node-Network geben"/>
|
||||
<node CREATED="1719188209270" ID="ID_207282130" MODIFIED="1719188231525" TEXT="von diesem wäre dann der Sinn der aufzubauenden Verdrahtung abzulesen"/>
|
||||
<node CREATED="1719188232382" ID="ID_246650360" MODIFIED="1719188252195">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
aber erwartungsgemäß hat man das<i> eben grade nicht</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1719188256485" ID="ID_1054880063" MODIFIED="1719188272666">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...sondern nur einen <b>lokalen</b> Kontext
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715177839667" ID="ID_677541762" MODIFIED="1715177851322" TEXT="muß Basis der StreamTypes klären">
|
||||
|
|
@ -81373,6 +81435,107 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1719190826274" ID="ID_1468761393" MODIFIED="1719190836070" TEXT="Stop! Neuanfang">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node CREATED="1719190839832" ID="ID_1276741051" MODIFIED="1719265986836" TEXT="ich verstehe diese alte Struktur nur ansatzweise">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...und ich kann mich erinnern, daß ich sie auch damals nicht vestanden habe, sondern mich immer nur von Definition zu Definition hangelte...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<linktarget COLOR="#ff004b" DESTINATION="ID_1276741051" ENDARROW="Default" ENDINCLINATION="460;0;" ID="Arrow_ID_1977387211" SOURCE="ID_295398317" STARTARROW="None" STARTINCLINATION="-52;188;"/>
|
||||
</node>
|
||||
<node CREATED="1719190856486" ID="ID_231251746" MODIFIED="1719191208897" TEXT="klar ist: diese Factory ist eine Notlösung, mit der der Code wenistens durch den Compiler geht">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
das ist die gradezu klassische »Top-down«-Falle:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
man definiert ausgehend von einem abstrakten Verständnis der Anforderungen (keinem echten Verständnis)
|
||||
</li>
|
||||
<li>
|
||||
jedes ungelöste Problem und jedes fehlende Verständnis wird jeweils als Anforderung in die nächste Detail-Ebene verschoben
|
||||
</li>
|
||||
<li>
|
||||
und beim Zusammenschalten der gebauten Teile steht man dann vor einem Wirrwarr, der nicht recht funktionieren will, aber immerhin alle präzise definierten (aber nicht verstandenen) Anforderungen erfüllt.
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1719191229476" ID="ID_569548140" MODIFIED="1719191277058" TEXT="die Node-Invocation lief mal in einem synthetischen Test — nicht aber die Factory">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1719191299780" ID="ID_1282527400" LINK="#ID_80068724" MODIFIED="1719191474292" TEXT="Beschluß: ich gestehe mir ein, daß eine Überarbeitung notwendig ist">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719191778055" ID="ID_1371082096" MODIFIED="1719191794282" TEXT="Anforderungen(Neufassung)">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1719191797712" ID="ID_1137038578" MODIFIED="1719191804128" TEXT="zu bauen ist...">
|
||||
<node CREATED="1719191806390" ID="ID_609110451" MODIFIED="1719191818113" TEXT="Several<Lead>">
|
||||
<node CREATED="1719191846295" ID="ID_1542014602" MODIFIED="1719191855452" TEXT="ein Lead adaptiert den Verweis auf eine Vorgänger-Node"/>
|
||||
</node>
|
||||
<node CREATED="1719191882287" ID="ID_566022685" MODIFIED="1719191886228" TEXT="Several<Port>">
|
||||
<node CREATED="1719191890019" ID="ID_1557787483" MODIFIED="1719191900278" TEXT="jeder Port muß mit einem Turnout hinterlegt werden"/>
|
||||
<node CREATED="1719191910608" ID="ID_54712734" MODIFIED="1719191933305" TEXT="dieser Turnout seinerseits braucht">
|
||||
<node CREATED="1719191950473" ID="ID_371186850" MODIFIED="1719191966573" TEXT="statische Parametrisierung ⟶ WeavingPattern">
|
||||
<node CREATED="1719191968961" ID="ID_1514113056" MODIFIED="1719191984290" TEXT="hier steckt die eignetliche Aufruf-Logik"/>
|
||||
<node CREATED="1719191985094" ID="ID_864150896" MODIFIED="1719192026869" TEXT="generisch formuliert — auf die konkrete Media-Lib spezialisiert"/>
|
||||
</node>
|
||||
<node CREATED="1719192063137" ID="ID_1981807460" MODIFIED="1719192156579" TEXT="Layout-Definition für die FeedManifold">
|
||||
<node CREATED="1719192180498" ID="ID_1633717544" MODIFIED="1719192201501" TEXT="Several<ref(Port)>"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719192502501" ID="ID_918766669" MODIFIED="1719192510569" TEXT="Spec für die Output-Buffer">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719192516511" ID="ID_258173965" MODIFIED="1719192592768" TEXT="klären: wie weden Buffer dargestellt?">
|
||||
<arrowlink COLOR="#df177d" DESTINATION="ID_1096257345" ENDARROW="Default" ENDINCLINATION="158;-1172;" ID="Arrow_ID_1559772795" STARTARROW="Default" STARTINCLINATION="286;142;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1719266961807" ID="ID_212820838" MODIFIED="1719266966386" TEXT="immer als BuffHandle">
|
||||
<node CREATED="1719267039599" ID="ID_339850468" MODIFIED="1719267048044" TEXT="ist leichtgewichtig">
|
||||
<node CREATED="1719267049029" ID="ID_1839021586" MODIFIED="1719267055704" TEXT="buff-*"/>
|
||||
<node CREATED="1719267056285" ID="ID_197481275" MODIFIED="1719267065625" TEXT="eine Metadaten-ID"/>
|
||||
<node CREATED="1719267070988" ID="ID_1327957867" MODIFIED="1719267075927" TEXT="BufferProvider back-*"/>
|
||||
</node>
|
||||
<node CREATED="1719267098792" ID="ID_333227912" MODIFIED="1719267115801" TEXT="verschiedene Provider können so in derselben Manifold gemischt werden"/>
|
||||
</node>
|
||||
<node CREATED="1719266991538" ID="ID_8146946" MODIFIED="1719267010802" TEXT="für DataSinks wird ein pseudo-BufferProvider dazwischengeschaltet">
|
||||
<node CREATED="1719267208862" ID="ID_1133348458" MODIFIED="1719269150001" TEXT="OutputSlot / DataSink gehört auf eine höhere Abstraktionsebene">
|
||||
<arrowlink COLOR="#5e0222" DESTINATION="ID_1793577189" ENDARROW="Default" ENDINCLINATION="648;-26;" ID="Arrow_ID_329940341" STARTARROW="None" STARTINCLINATION="-75;593;"/>
|
||||
<linktarget COLOR="#533f4c" DESTINATION="ID_1133348458" ENDARROW="Default" ENDINCLINATION="107;-878;" ID="Arrow_ID_208652263" SOURCE="ID_1877886821" STARTARROW="None" STARTINCLINATION="1479;81;"/>
|
||||
</node>
|
||||
<node CREATED="1719269177611" ID="ID_761451539" MODIFIED="1719269196253" TEXT="das Output-Slot-Protokoll operiert auf der Ebene des Frame-Job"/>
|
||||
<node CREATED="1719269206207" ID="ID_846303339" MODIFIED="1719269232359" TEXT="für die Einzelberechnung ist das lediglich ein Zielpuffer — der bereits bereitgestellt ist"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719276014384" ID="ID_274182619" MODIFIED="1719276023591" TEXT="Entwurf syntaktische Struktur">
|
||||
<node CREATED="1719276025136" ID="ID_607906936" MODIFIED="1719276042313" TEXT="buildPatternFor<ONT>()">
|
||||
<node CREATED="1719277198122" ID="ID_1431538917" MODIFIED="1719277212004" TEXT="ONT ist eine Domänen-Ontologie">
|
||||
<node CREATED="1719277214775" ID="ID_1364518400" MODIFIED="1719277219923" TEXT="Beispiel FFmpeg"/>
|
||||
<node CREATED="1719277220672" ID="ID_973384222" MODIFIED="1719277530648" TEXT="konkret: TestRandOntology">
|
||||
<arrowlink COLOR="#df3950" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="666;-662;" ID="Arrow_ID_801625266" STARTARROW="None" STARTINCLINATION="-521;54;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715472577657" ID="ID_302214544" MODIFIED="1715472583381" TEXT="Conststituents">
|
||||
<node CREATED="1715522273278" ID="ID_1913846736" MODIFIED="1715522278674" TEXT="Connectivity">
|
||||
|
|
@ -85012,7 +85175,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1718926023053" ID="ID_1064805768" MODIFIED="1718926095493" TEXT="Verbindung mit der Node-Struktur neu ordnen">
|
||||
<linktarget COLOR="#80418c" DESTINATION="ID_1064805768" ENDARROW="Default" ENDINCLINATION="347;215;" ID="Arrow_ID_1648312561" SOURCE="ID_1898452649" STARTARROW="None" STARTINCLINATION="148;-17;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1718926109744" ID="ID_80068724" MODIFIED="1718926113329" TEXT="was mich stört">
|
||||
<node COLOR="#5b280f" CREATED="1718926109744" ID="ID_80068724" MODIFIED="1719191543432" TEXT="was mich stört">
|
||||
<linktarget COLOR="#b80202" DESTINATION="ID_80068724" ENDARROW="Default" ENDINCLINATION="16;334;" ID="Arrow_ID_261689280" SOURCE="ID_943512919" STARTARROW="Default" STARTINCLINATION="0;-193;"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1718926114200" ID="ID_1305470404" MODIFIED="1718926280052" TEXT="die vielen Indirektionen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -85089,7 +85254,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1718932460163" ID="ID_846170415" MODIFIED="1718932474781" TEXT="die Node muß ohne Turnout-System verständlich sein"/>
|
||||
<node CREATED="1718932475681" ID="ID_119429683" MODIFIED="1718932573975" TEXT="das Turnout-System muß aus den Ports rekursiv hervorgehen"/>
|
||||
<node CREATED="1718932576531" ID="ID_1954245677" MODIFIED="1718932597076" TEXT="mit dem Turnout-System wird die konkrete Buffer-Verwaltung hinzugefürt (Feed-Manifold)"/>
|
||||
<node CREATED="1718932576531" ID="ID_1954245677" MODIFIED="1718932597076" TEXT="mit dem Turnout-System wird die konkrete Buffer-Verwaltung hinzugefügt (Feed-Manifold)"/>
|
||||
<node CREATED="1719275534689" ID="ID_396627461" MODIFIED="1719275554471" TEXT="es müssen aber auch Informationen transportiert werden">
|
||||
<node CREATED="1719275555943" ID="ID_190750298" MODIFIED="1719275563169" TEXT="die Instanz-Koordinaten"/>
|
||||
<node CREATED="1719275563757" ID="ID_304657123" MODIFIED="1719275640726" TEXT="Cache-Keys auf jeder Ebene">
|
||||
<linktarget COLOR="#ac5878" DESTINATION="ID_304657123" ENDARROW="Default" ENDINCLINATION="2911;290;" ID="Arrow_ID_1615410848" SOURCE="ID_577334967" STARTARROW="None" STARTINCLINATION="-968;-56;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823682795" ID="ID_868323088" MODIFIED="1713823821819" TEXT="Klären der Probleme mit den Prototypen">
|
||||
|
|
@ -85131,13 +85302,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1713823944920" ID="ID_1929417005" MODIFIED="1713823954451" TEXT="Node muß 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 BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186374543" ID="ID_1706482104" MODIFIED="1719277437612" TEXT="Test-Ontologie aufbauen">
|
||||
<arrowlink COLOR="#ff2400" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="-136;-44;" ID="Arrow_ID_1657525718" STARTARROW="None" STARTINCLINATION="101;9;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</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 CREATED="1713823362710" ID="ID_66967253" MODIFIED="1719277373397" TEXT="Hilfsmittel zur Entwicklung und zum Aufbau">
|
||||
<node CREATED="1719277267208" HGAP="29" ID="ID_594112005" MODIFIED="1719277530648" TEXT="brauche eine komplette Test-Ontologie" VSHIFT="7">
|
||||
<linktarget COLOR="#ff2400" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="-136;-44;" ID="Arrow_ID_1657525718" SOURCE="ID_1706482104" STARTARROW="None" STARTINCLINATION="101;9;"/>
|
||||
<linktarget COLOR="#df3950" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="666;-662;" ID="Arrow_ID_801625266" SOURCE="ID_973384222" STARTARROW="None" STARTINCLINATION="-521;54;"/>
|
||||
<node CREATED="1719277376922" ID="ID_420782384" MODIFIED="1719277398435" TEXT="das ist zugleich ein Prüfstein für das angestrebte »generische Design«"/>
|
||||
<node CREATED="1719277401015" ID="ID_1540154009" MODIFIED="1719277423128" TEXT="muß alle Operationen bereitstellen, die für abstrakte Tests notwendig sind"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1713821694886" ID="ID_1102491970" MODIFIED="1718843733168" TEXT="NodeLinkage_test">
|
||||
<linktarget COLOR="#fdd3b6" DESTINATION="ID_1102491970" ENDARROW="Default" ENDINCLINATION="-366;-51;" ID="Arrow_ID_1227159439" SOURCE="ID_943908122" STARTARROW="None" STARTINCLINATION="30;255;"/>
|
||||
|
|
@ -85155,7 +85337,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1718925986694" ID="ID_1898452649" MODIFIED="1718926069047" TEXT="Struktur der Connectivity neu aufbauen">
|
||||
<arrowlink COLOR="#80418c" DESTINATION="ID_1064805768" ENDARROW="Default" ENDINCLINATION="347;215;" ID="Arrow_ID_1648312561" STARTARROW="None" STARTINCLINATION="148;-17;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1718927862012" ID="ID_943512919" MODIFIED="1718927879670" TEXT="diesen Code einfach nur zu verwenden wäre verantwortungslos">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1718927862012" ID="ID_943512919" MODIFIED="1719191518521" TEXT="diesen Code einfach nur zu verwenden wäre verantwortungslos">
|
||||
<arrowlink COLOR="#b80202" DESTINATION="ID_80068724" ENDARROW="Default" ENDINCLINATION="16;334;" ID="Arrow_ID_261689280" STARTARROW="Default" STARTINCLINATION="0;-193;"/>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1718927843580" ID="ID_1971619594" MODIFIED="1718927889643" TEXT="ich muß wohl die Invocation-Sequenz nochmal durchdenken">
|
||||
|
|
@ -85324,17 +85507,99 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1719161926326" ID="ID_639065262" MODIFIED="1719161950902" TEXT="bezieht von diesem die Dependency-Injection">
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1719162633670" ID="ID_460645690" MODIFIED="1719162641407" TEXT="Klärungsbedarf hier">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719162643254" ID="ID_1096257345" MODIFIED="1719162673158" TEXT="BufferProvider oder Buffer Handles?">
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719162643254" ID="ID_1096257345" MODIFIED="1719192592768" TEXT="BufferProvider oder Buffer Handles?">
|
||||
<linktarget COLOR="#df177d" DESTINATION="ID_1096257345" ENDARROW="Default" ENDINCLINATION="158;-1172;" ID="Arrow_ID_1559772795" SOURCE="ID_258173965" STARTARROW="Default" STARTINCLINATION="286;142;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1719270916096" ID="ID_1369086348" MODIFIED="1719270950759" TEXT="zunächst einmal: die relevanten BufferProvider müssen greifbar sein"/>
|
||||
<node CREATED="1719270992078" ID="ID_1244150995" MODIFIED="1719271008269" TEXT="man könnte aber auch an einen festen Satz bereits belegter Handles denken"/>
|
||||
<node COLOR="#5b280f" CREATED="1719271015059" ID="ID_243357354" MODIFIED="1719272327704" TEXT="das wäre eine Art »L1 Cache«">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1719271053247" ID="ID_1450680178" MODIFIED="1719271070832" TEXT="genau zu durchdenken, ob sinnvoll!">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1719271075779" ID="ID_363466209" MODIFIED="1719271096622" TEXT="ist eine gewisse Verschwendung"/>
|
||||
<node CREATED="1719271102992" ID="ID_1849579208" MODIFIED="1719271117264" TEXT="könnte unversehends für zusätzlichen Admin Aufwand sorgen"/>
|
||||
<node CREATED="1719271127596" ID="ID_1128397704" MODIFIED="1719271146317" TEXT="ist in jedem Fall komplex und eine tückische Fehlerquelle"/>
|
||||
<node CREATED="1719271214216" ID="ID_398640235" MODIFIED="1719271313974" TEXT="der generische Buffer-Provider muß ohnehin ein optimiertes Pooling bieten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...und zwar mit einer Gruppierung der Buffer nach Größe, und vermutlich auch pro Thread
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1719272305095" ID="ID_1538638979" MODIFIED="1719272324423" TEXT="also besser mal Finger weg">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719162654773" ID="ID_1902060576" MODIFIED="1719162671608" TEXT="wer bekommt einen OutputSlot, und wer eine (geöffnete) DataSink?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1719272358349" ID="ID_530721901" MODIFIED="1719272392304" TEXT="der Job bekommt eine DataSink"/>
|
||||
<node CREATED="1719272470222" ID="ID_1647993969" MODIFIED="1719272488848" TEXT="der Job muß davon im Zeitfenster die DataSink(s) allozieren">
|
||||
<node CREATED="1719272576443" ID="ID_1737558324" MODIFIED="1719272787633" TEXT="es können mehrere DataSinks sein">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Es kann durchaus sein, daß das jeweilige Output-System einzelne Teil-Kanäle in einem <i>planaren Format </i>haben möchte, also als einzelne, zusammenhängende Datenblöcke für jeden Kanal (Hue, Sat, Lum, bzw. Sound-L/R oder WXYZ...)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1719272606004" ID="ID_373024645" MODIFIED="1719272632021" TEXT="in diesem Fall muß die top-Level-Node auch mehrere Output-Buffer liefern"/>
|
||||
<node CREATED="1719272633589" ID="ID_920731702" MODIFIED="1719272647394" TEXT="trotzdem muß das alles zusammen in einem Aufruf passieren"/>
|
||||
</node>
|
||||
<node CREATED="1719272545639" ID="ID_1693983155" MODIFIED="1719272569733" TEXT="diese gibt er dann an das TurnoutSytem(top-level) weiter"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719162675146" ID="ID_232913712" MODIFIED="1719162681897" TEXT="wie wird der Cache eingebunden?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719162701531" ID="ID_1485038831" MODIFIED="1719162725509" TEXT="der Cache muß einen Frame-Key zu jedem Buffer bekommen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1719274449895" ID="ID_246452729" MODIFIED="1719274464706" TEXT="dieses Thema wurde bisher noch nicht betrachtet">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1719274466738" ID="ID_1523555394" MODIFIED="1719274526206" TEXT="es ist aber sicherlich lösbar">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1719274477032" ID="ID_1597306488" MODIFIED="1719274490387" TEXT="etweder über die Metadaten-Infrastruktur im BufferProvider"/>
|
||||
<node CREATED="1719274491006" ID="ID_708988075" MODIFIED="1719274516673" TEXT="oder indem man noch einen Header in den Buffer für den Cache-Entry einbaut"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1719274528595" ID="ID_1941129738" MODIFIED="1719275284591" TEXT="insofern kann man das Thema derzeit ignorieren">
|
||||
<arrowlink COLOR="#be5682" DESTINATION="ID_296714720" ENDARROW="Default" ENDINCLINATION="8;-27;" ID="Arrow_ID_1041581476" STARTARROW="None" STARTINCLINATION="-86;5;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1719274608878" ID="ID_870491160" MODIFIED="1719274632551" TEXT="zum Thema »Frame Cache« gibt es noch nichteinmal Tickets"/>
|
||||
<node CREATED="1719274656967" ID="ID_1180302516" LINK="https://issues.lumiera.org/report/17" MODIFIED="1719274731396" TEXT="es ist auch nicht bei den Focus-Topics dabei"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719275186152" ID="ID_296714720" MODIFIED="1719275286013" TEXT="Aber die Aufgabe im Blick behalten: Info von Node+Invocation ⟶ Cache">
|
||||
<linktarget COLOR="#be5682" DESTINATION="ID_296714720" ENDARROW="Default" ENDINCLINATION="8;-27;" ID="Arrow_ID_1041581476" SOURCE="ID_1941129738" STARTARROW="None" STARTINCLINATION="-86;5;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1719275318407" ID="ID_1392911369" MODIFIED="1719275366650" TEXT="das muß vor / jenseits des normalen pull()-Schemas passieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
warum? weil es die BufferManager-Abstraktion unterläuft
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719275367776" ID="ID_577334967" MODIFIED="1719275640725" TEXT="insofern ist es genau eine Aufgabe für das Turnout-System">
|
||||
<arrowlink COLOR="#ac5878" DESTINATION="ID_304657123" ENDARROW="Default" ENDINCLINATION="2911;290;" ID="Arrow_ID_1615410848" STARTARROW="None" STARTINCLINATION="-968;-56;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719275655556" ID="ID_676493203" MODIFIED="1719275679282" TEXT="abgesehen davon: der Cache ist als ein weiterer BufferProvider „versteckt“"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719162376624" ID="ID_40367188" MODIFIED="1719162389506" TEXT="output slots"/>
|
||||
|
|
@ -85408,6 +85673,17 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1718975871248" ID="ID_522836015" MODIFIED="1718975888569" TEXT="die faßt die Schritte zusammen, die man auch explizit machen kann"/>
|
||||
<node CREATED="1718975902428" ID="ID_1445965423" MODIFIED="1718975920749" TEXT="vorzugsweise gibt es einzelne Builder-Functions für Turnout"/>
|
||||
<node CREATED="1718975923921" ID="ID_620438698" MODIFIED="1718975932092" TEXT="hinzu kommt außerdem der AllocationCluster"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719276278262" ID="ID_670231517" MODIFIED="1719276307022" TEXT="aber Node-Wiring kann jetzt schon angepaßt werden">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1719276313964" ID="ID_1044365702" MODIFIED="1719276352131" TEXT="nodewiring.hpp ⟼ nodewiring-obsolete.hpp"/>
|
||||
<node CREATED="1719276447012" ID="ID_690909625" MODIFIED="1719276472197" TEXT="die bisherige WiringSituation dort einfach inlinen (bis wir sie wegwerfen)">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1719276226613" ID="ID_305778112" MODIFIED="1719276363933" TEXT="WiringSituation ⟼ NodeWiringBuilder kann jetzt schon umgebaut werden"/>
|
||||
<node CREATED="1719276365051" ID="ID_105665279" MODIFIED="1719276382947" TEXT="wird nur von Tests konsumiert, die jetzt konkret auf der Agenda stehen">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1718975949293" ID="ID_8397683" MODIFIED="1718975957653" TEXT="noch unklar: Weaving-Patterns?">
|
||||
<icon BUILTIN="help"/>
|
||||
|
|
@ -85424,6 +85700,67 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719181051848" ID="ID_1552638838" MODIFIED="1719182620319" TEXT="Ziel für diesen Testfall">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719181203922" ID="ID_1630163115" MODIFIED="1719182613749" TEXT="Nodes bauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1719181208787" ID="ID_1934059766" MODIFIED="1719182250419" TEXT="eine Quell-Node mit zwei Ports">
|
||||
<icon BUILTIN="full-1"/>
|
||||
</node>
|
||||
<node CREATED="1719181289558" ID="ID_1967826855" MODIFIED="1719182252664" TEXT="Node mit einem Lead und zwei Ports">
|
||||
<icon BUILTIN="full-2"/>
|
||||
</node>
|
||||
<node CREATED="1719181653608" ID="ID_1478309261" MODIFIED="1719182255048" TEXT="Node mit zwei Leads und drei Ports">
|
||||
<icon BUILTIN="full-3"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719182150605" ID="ID_1115772240" MODIFIED="1719182613748" TEXT="prüfen...">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1719182162476" ID="ID_216827263" MODIFIED="1719182257696" TEXT="hinter jedem Port steckt ein markierter Turnout">
|
||||
<icon BUILTIN="full-1"/>
|
||||
</node>
|
||||
<node CREATED="1719182222333" ID="ID_1783268362" MODIFIED="1719182302909" TEXT="Struktur der Manifold">
|
||||
<icon BUILTIN="full-2"/>
|
||||
<node CREATED="1719182335669" ID="ID_1014404062" MODIFIED="1719182463944" TEXT="jeder Turnout hat einen Quell-Port"/>
|
||||
<node CREATED="1719182351192" ID="ID_1248520841" MODIFIED="1719182372167" TEXT="diese ensprechen den Ports des Lead"/>
|
||||
</node>
|
||||
<node CREATED="1719182383030" ID="ID_1828048731" MODIFIED="1719182633337" TEXT="Struktur der Manifold">
|
||||
<icon BUILTIN="full-3"/>
|
||||
<node CREATED="1719182426384" ID="ID_1676547159" MODIFIED="1719182472679" TEXT="jeder der drei Turnouts hat Quell-Port der auf einen der Leads führt"/>
|
||||
<node CREATED="1719184331652" ID="ID_547519197" MODIFIED="1719184361531" TEXT="die anderen sind jeweils belegt wie im Setup konfiguriert"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719185907166" ID="ID_103991417" MODIFIED="1719185913917" TEXT="Implementierung treiben">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1719185917965" ID="ID_1211128567" MODIFIED="1719185925767" TEXT="zu klären">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719185927515" ID="ID_977612187" MODIFIED="1719185936043" TEXT="wie werden Nodes gebaut?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719185943913" ID="ID_393811539" MODIFIED="1719185992634" TEXT="was ist die Identität einer Node?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719186031309" ID="ID_1908240557" MODIFIED="1719186091788" TEXT="kann man die Identität eines Turnout feststellen?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186096499" ID="ID_1104635186" MODIFIED="1719186122029" TEXT="Diagnose-Setup">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186160563" ID="ID_1991257351" MODIFIED="1719186169979" TEXT="Interna eines Turnout auslesen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186204738" ID="ID_228985489" MODIFIED="1719186208982" TEXT="Testdatenquelle">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186220945" ID="ID_1096357803" MODIFIED="1719186228089" TEXT="verifizierbare Test-Operation">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719186257383" ID="ID_1944249057" MODIFIED="1719186263807" TEXT="Test-Datensenke">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1718843534139" ID="ID_1144935511" MODIFIED="1718843607043" TEXT="Turnout-System aufbauen">
|
||||
<icon BUILTIN="full-2"/>
|
||||
|
|
@ -85440,6 +85777,19 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1719163902717" ID="ID_1815065175" MODIFIED="1719163924443" TEXT="erscheit mir aber im Moment zweifelhaft (nicht klar was StateClosure noch soll....)">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1719176564725" ID="ID_1676094171" MODIFIED="1719176859858" TEXT="man könnte wohl den gleichen Effekt mit einer expliziteren Dependency-Injection erzielen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...weiterhin bleibt es dabei, daß der Zugang zum Buffer-Management über das Turnout-System (früher StateAdapter) läuft; aber dafür ist kein klassisches OO-Interface notwendig, sofern das Buffer-Handling seinerseits auf einem Interface aufbaut. Die Aufgabe, an der sich das entscheidet ist, wie der konkrete Turnout eine konkrete FeedManifold bauen kann (und ob er das überhaupt tut)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -85455,7 +85805,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</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 BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1719282799123" ID="ID_605400011" MODIFIED="1719282822229" TEXT="muß ich erst einmal größtenteils auskommentieren">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823489509" ID="ID_738439301" MODIFIED="1719282837986" TEXT="idealerweise nebenbei neu mit aufbauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1713821728361" ID="ID_1456365802" MODIFIED="1713823527161" TEXT="NodeFactory_test">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
|
|
@ -85545,6 +85900,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711548381477" ID="ID_664146362" MODIFIED="1711552950392" TEXT="Buffer-Manager">
|
||||
<linktarget COLOR="#fec499" DESTINATION="ID_664146362" ENDARROW="Default" ENDINCLINATION="-1409;197;" ID="Arrow_ID_616778881" SOURCE="ID_722733788" STARTARROW="None" STARTINCLINATION="-794;96;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1719249646221" ID="ID_403017464" MODIFIED="1719249923835" TEXT="Begriffe klarstellen">
|
||||
<arrowlink COLOR="#4b5a6c" DESTINATION="ID_1263834914" ENDARROW="Default" ENDINCLINATION="-668;-90;" ID="Arrow_ID_767640863" STARTARROW="None" STARTINCLINATION="-873;115;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1719248935388" ID="ID_230230853" MODIFIED="1719248961948" TEXT="Buffer-Management ≙ Output-Management"/>
|
||||
</node>
|
||||
<node CREATED="1711548396996" ID="ID_235150337" MODIFIED="1711548402527" TEXT="Aufgaben">
|
||||
<node CREATED="1711548418633" ID="ID_1733032453" MODIFIED="1711548429479" TEXT="stellt einen Pool von Buffer-Datenblöcken bereit">
|
||||
<node CREATED="1711548445237" ID="ID_138352445" MODIFIED="1711548503761" TEXT="dafür wird ein Speicher-Reservoir vorbelegt"/>
|
||||
|
|
@ -124390,24 +124750,32 @@ std::cout << tmpl.render({"what", "World"}) << s
|
|||
</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">
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="26" 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">
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="12" ID="ID_1249060254" MODIFIED="1713825443352" TEXT="wird vermutlich umbenannt">
|
||||
<font NAME="SansSerif" SIZE="10"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1713825230197" ID="ID_1105758480" MODIFIED="1713825233824" TEXT="StateProxy">
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1713825129642" HGAP="28" ID="ID_1834796012" MODIFIED="1719242491516" TEXT="mutmaßlich wegfallend" 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 BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1719243014832" ID="ID_1997352135" MODIFIED="1719243053242" TEXT="alles komplett überarbeiten">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1702415745677" ID="ID_889077707" MODIFIED="1702416408821" TEXT="Website">
|
||||
|
|
@ -124460,6 +124828,32 @@ std::cout << tmpl.render({"what", "World"}) << s
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1719248904305" ID="ID_1263834914" MODIFIED="1719249923835" TEXT="Datenausgabe-Begriffe">
|
||||
<linktarget COLOR="#4b5a6c" DESTINATION="ID_1263834914" ENDARROW="Default" ENDINCLINATION="-668;-90;" ID="Arrow_ID_767640863" SOURCE="ID_403017464" STARTARROW="None" STARTINCLINATION="-873;115;"/>
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1719248935388" ID="ID_617181865" MODIFIED="1719268724291" TEXT="Buffer-Management ≙ Output-Management">
|
||||
<linktarget COLOR="#494b7a" DESTINATION="ID_617181865" ENDARROW="Default" ENDINCLINATION="-882;-55;" ID="Arrow_ID_987434698" SOURCE="ID_1877886821" STARTARROW="None" STARTINCLINATION="-1297;72;"/>
|
||||
</node>
|
||||
<node CREATED="1719248978957" ID="ID_1526659438" MODIFIED="1719248990921" TEXT="BufferProvider">
|
||||
<node CREATED="1719248991858" ID="ID_1208921811" MODIFIED="1719249009087" TEXT="generische Schnittstelle als Zugang zu abstrahierten Buffern"/>
|
||||
<node CREATED="1719249009802" ID="ID_1115060096" MODIFIED="1719249028945" TEXT="ein konkreter Buffer-Typ wird vom client als Overlay angegeben"/>
|
||||
<node CREATED="1719249143713" ID="ID_1884572024" MODIFIED="1719249151447" TEXT="stellt ein BuffHandle bereit"/>
|
||||
</node>
|
||||
<node CREATED="1719249067047" ID="ID_860520674" MODIFIED="1719249077469" TEXT="OutputManager">
|
||||
<node CREATED="1719249078625" ID="ID_1793577189" MODIFIED="1719269049808" TEXT="Definition: ein konkreter Service zur Verwaltung externer Ausgaben">
|
||||
<arrowlink COLOR="#890814" DESTINATION="ID_599503027" ENDARROW="Default" ENDINCLINATION="-447;649;" ID="Arrow_ID_1542547570" STARTARROW="None" STARTINCLINATION="-1299;-27;"/>
|
||||
<linktarget COLOR="#5e0222" DESTINATION="ID_1793577189" ENDARROW="Default" ENDINCLINATION="648;-26;" ID="Arrow_ID_329940341" SOURCE="ID_1133348458" STARTARROW="None" STARTINCLINATION="-75;593;"/>
|
||||
</node>
|
||||
<node CREATED="1719249123235" ID="ID_1315654847" MODIFIED="1719249219458" TEXT="stellt nach Mapping / Verhandlung einen OutputSlot bereit">
|
||||
<node CREATED="1719249330191" ID="ID_1788980286" MODIFIED="1719249342069" TEXT="zunächst gibt es nur eine symbolische OutputDesignation"/>
|
||||
<node CREATED="1719249342726" ID="ID_1193969502" MODIFIED="1719249358104" TEXT="man geht zu einem OutputManager und beschafft sich dafür einen OutputSlot"/>
|
||||
</node>
|
||||
<node CREATED="1719249154255" ID="ID_1122091552" MODIFIED="1719249310054" TEXT="diese wird per »Allokations«-Operation ⟼ { DataSink, ...}*N"/>
|
||||
<node CREATED="1719249373786" ID="ID_1927055015" MODIFIED="1719249383277" TEXT="in diesem Fall gibt es auch Timing-Anforderungen">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1680563506475" ID="ID_53985081" MODIFIED="1680563509211" TEXT="Interface">
|
||||
<node CREATED="1681341888374" ID="ID_1288070081" MODIFIED="1681341890674" TEXT="Konzepte">
|
||||
|
|
|
|||
Loading…
Reference in a new issue