diff --git a/src/steam/engine/feed-manifold.hpp b/src/steam/engine/feed-manifold.hpp index 7fcc86b75..52183e62f 100644 --- a/src/steam/engine/feed-manifold.hpp +++ b/src/steam/engine/feed-manifold.hpp @@ -58,8 +58,16 @@ ** - the trait functions #hasInput() and #hasParam() should be used by downstream code ** to find out if some part of the storage is present and branch accordingly ** @todo 12/2024 figure out how constructor-arguments can be passed flexibly - ** @todo staled since 2009, picked up in 2024 in an attempt to finish the node invocation. - ** @todo WIP-WIP 2024 rename and re-interpret as a connection system + ** @remark in the first draft version of the Render Engine from 2009/2012, there was an entity + ** called `BuffTable`, which however provided additional buffer-management functionality. + ** This name describes well the basic functionality, which can be hard to see with all + ** this additional meta-programming related to the flexible functor signature. When it + ** comes to actual invocation, we collect input buffers from predecessor nodes and + ** we prepare output buffers, and then we pass both to a processing function. + ** + ** @todo WIP-WIP 12/2024 now about to introduce support for arbitrary parameters into the + ** Render-Engine code, which has been reworked for the »Playback Vertical Slice«. + ** We have still to reach the point were the engine becomes operational!!! ** @see NodeBase_test ** @see weaving-pattern-builder.hpp */ @@ -75,6 +83,7 @@ #include "steam/engine/buffhandle.hpp" #include "lib/uninitialised-storage.hpp" #include "lib/meta/function.hpp" +#include "lib/meta/trait.hpp" #include "lib/meta/typeseq-util.hpp" //#include "lib/several.hpp" @@ -82,7 +91,7 @@ //#include -////////////////////////////////TICKET #826 will be reworked alltogether +////////////////////////////////TICKET #826 12/2024 the invocation sequence has been reworked and reoriented for integration with the Scheduler namespace steam { namespace engine { @@ -206,26 +215,67 @@ namespace engine { using SigI = _Arg::SLOT_I>; using SigO = _Arg::SLOT_O>; + using SigP = _Arg; using BuffI = typename _ArgTrait::Buff; using BuffO = typename _ArgTrait::Buff; enum{ FAN_I = _ArgTrait::SIZ , FAN_O = _ArgTrait::SIZ + , FAN_P = _ArgTrait::SIZ , SLOT_I = _Case::SLOT_I , SLOT_O = _Case::SLOT_O + , SLOT_P = 0 , MAXSZ = std::max (uint(FAN_I), uint(FAN_O)) /////////////////////OOO required temporarily until the switch to tuples }; static constexpr bool hasInput() { return SLOT_I != SLOT_O; } static constexpr bool hasParam() { return 0 < SLOT_I; } }; + + + template + struct ParamStorage + { + using ParSig = typename _ProcFun::SigP; + ParSig param; + }; + + template + struct BufferSlot_Input + { + using BuffS = lib::UninitialisedStorage::FAN_I>; + using ArgSig = typename _ProcFun::SigI; + + BuffS inBuff; + ArgSig inArgs; + }; + + template + struct BufferSlot_Output + { + using BuffS = lib::UninitialisedStorage::FAN_O>; + using ArgSig = typename _ProcFun::SigO; + + BuffS outBuff; + ArgSig outArgs; + }; + + template + struct NotProvided : lib::meta::NullType { }; + + template + using Provide_if = std::conditional_t>; }//(End)Introspection helpers. + template struct FeedManifold_StorageSetup : util::NonCopyable + , BufferSlot_Output + , Provide_if<_ProcFun::hasInput(), BufferSlot_Input> + , Provide_if<_ProcFun::hasParam(), ParamStorage> { }; @@ -239,7 +289,7 @@ namespace engine { * This setup is used by a »weaving pattern« within the invocation of a processing node for the * purpose of media processing or data calculation. * - * @todo WIP-WIP-WIP 7/24 now reworking the old design in the light of actual render engine requirements... + * @todo WIP-WIP 12/24 now adding support for arbitrary parameters /////////////////////////////////////TICKET #1386 */ template struct FoldManifeed diff --git a/tests/core/steam/engine/node-base-test.cpp b/tests/core/steam/engine/node-base-test.cpp index f7c2d41bb..c833db28b 100644 --- a/tests/core/steam/engine/node-base-test.cpp +++ b/tests/core/steam/engine/node-base-test.cpp @@ -23,6 +23,8 @@ #include "steam/engine/turnout.hpp" #include "steam/engine/turnout-system.hpp" #include "steam/engine/feed-manifold.hpp" +#include "steam/engine/diagnostic-buffer-provider.hpp" +#include "steam/engine/buffhandle-attach.hpp" //#include "lib/format-cout.hpp" //#include "lib/util.hpp" @@ -80,6 +82,21 @@ namespace test { using M1 = FeedManifold; CHECK (not M1::hasInput()); CHECK (not M1::hasParam()); + M1 m1{}; + CHECK (1 == m1.outBuff.array().size()); + CHECK (nullptr == m1.outArgs ); +// CHECK (m1.inArgs ); // does not compile because storage field is not provided +// CHECK (m1.param ); + + BufferProvider& provider = DiagnosticBufferProvider::build(); + BuffHandle buff = provider.lockBufferFor(); ////////////////////////////OOO can not pass ctor-args directly here +buff.accessAs() = -55; + CHECK (buff.isValid()); + CHECK (buff.accessAs() == -55); + + m1.outBuff.createAt (0, buff); + CHECK (m1.outBuff[0].isValid()); + CHECK (m1.outBuff[0].accessAs() == -55); } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 39418e99a..cfed671e4 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -23948,9 +23948,7 @@ - - - +

isnil (profile_) @@ -24591,9 +24589,7 @@ - - - +

erst mal nur mit einem Button, und die Layout-Logik ehr "geschätzt" den präzise verstanden und umgesetzt. Immerhinn läuft der DisplayEvaluationPass nun, und auch die Buttons erscheinen an der Stelle, an der ich das erwarten würde... @@ -25183,9 +25179,7 @@ - - - +

also z.B: wenn man das TestControl schließt, oder auch nur den Fokus an das Lumiera-Hauptfenster gibt @@ -25940,9 +25934,7 @@ - - - +

und müßte es danach explizit manuell löschen!! @@ -27077,9 +27069,7 @@ - - - +

man zeichnet nicht, sondern man stellt eine Liste von Operationen zusammen @@ -28909,9 +28899,7 @@ - - - +

d.h er funktioniert nur, wenn man das std::get<idx> (tuple) unmittelbar an den jeweiligen Ziel-Parameter bindet @@ -29154,9 +29142,7 @@ - - - +

...etwas analog zu meinem TreeMutator. @@ -32839,9 +32825,7 @@ - - - +

und ja, den Screen sollte man generell setzten.
Steht auch so in der Doku. @@ -33526,9 +33510,7 @@ - - - +

daher Policy ändern: jeder schlägt den totalen absoluten  Offset drauf @@ -35555,9 +35537,7 @@ - - - +

Zum Abschluß der GUI-Überarbeitung 3/23 habe ich diese Zombie-Timeline tot gemacht @@ -36847,9 +36827,7 @@ - - - +

  • @@ -37544,9 +37522,7 @@ - - - +

    Registry hat zusätzlichen Overhead (sowohl Speicher, alsauch Management) und ist nur sinnvoll, wenn eine ID in mehreren Objekten vorkommt, oder die ID aus mehreren Thread-Kontexten benötigt wird @@ -37903,9 +37879,7 @@ - - - +

    habs in error.hpp untergebracht, direkt unter ERROR_LOG_AND_IGNORE @@ -38668,9 +38642,7 @@ - - - +

    ...wenn man nun eine fest-vorbereitete Lösung für jeden Fall vorsieht, wird die Schnittstelle bereit, unübersichtlich und könnte im Lauf der Zeit verwuchern. Zudem muß eine komplexe Konvention errichtet werden, wer wann für wen welche Variante aufruft @@ -88539,6 +88511,124 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

    +     template<class X, typename...ARGS> +

    +

    +     inline void +

    +

    +     buildIntoBuffer (void* storageBuffer, ARGS&& ...args) +

    +

    +     { +

    +

    +       new(storageBuffer) X(forward<ARGS> (args)...); +

    +

    +     } +

    +

    + +

    +

    + +

    +

    +       template<class X, typename...ARGS> +

    +

    +       static TypeHandler +

    +

    +       create (ARGS&& ...args) +

    +

    +         { +

    +

    +           return TypeHandler ( bind (buildIntoBuffer<X,ARGS...>, _1, forward<ARGS> (args)...) +

    +

    +                              , destroyInBuffer<X>); +

    +

    +         } +

    + + +     +     + + + + + + +

    + no matching function for call to +

    +

    +   std::function<void(void*)>::function(std::_Bind<void (*(std::_Placeholder<1>, int))(void*, int&&)>&) +

    + + +     +     + + + + + +

    + with CTOR = std::_Bind<void (*(std::_Placeholder<1>, int))(void*, int&&)>; +

    + + +     + +     +     + + + + +     + + + + + @@ -91417,8 +91507,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    vorsicht Falle: Parameter werden oft per Referenz genommen

    - - +     @@ -91443,8 +91532,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ich muß für die strukturierten Fälle eine eingene Trait-Spezialisierung anlegen

    - - +     @@ -91463,8 +91551,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + @@ -91489,8 +91577,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Denn der weitere darauf aufbauende Code ist ebenfalls nicht ganz in Ordnung und benötigt die Generalisierung, um dann grade gezogen zu werden... und ich fürchte die Situation, wo mir ein Berg von Template-Code um die Ohren fliegt

    - - +     @@ -91786,7 +91873,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + + @@ -91832,8 +91920,27 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         + + + + + +

    + Für die BuffTable war früher jede Menge Funktionalität geplant, die inzwischen im BufferProvider realisiert wurde; der alte Test hängt seit >10 Jahren bei den Engine-Tests unimplementiert mit rum — es ist sinnlos, ihn nun umzuwidmen +

    + + +     +     - + + + + + + +     +