benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_documentation/tests/steam/engine/output-proxy-provider-test.cpp

95 lines
3.1 KiB
C++
Raw Normal View History

Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
/*
OutputProxyProvider(Test) - verify accessing an output sink via BufferProvider protocol
Copyright (C)
2024, Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
* *****************************************************************/
Upgrade: improve Doxygen parameters and treat some warnings - remove obsolete configuration settings - walk through all settings according to the documentation https://www.doxygen.nl/manual/config.html - now try to use the new feature to rely on Clang for C++ parsing - walk through the doxygen-warnings.txt and fix some obvious misspellings and structural problems in the documentation comments. With Debian-Trixie, we are now using Doxygen 1.9.8 — which produces massively better results in various fine points. However, there are still problems with automatic cross links, especially from implementation to the corresponding test classes.
2025-04-26 23:59:29 +02:00
/** @file output-proxy-provider-test.cpp
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
** unit test \ref OutputProxyProvider_test
*/
Tests: build an link a test-support library This is something I wanted to clean-up since a very long time indeed, but always postponed it, since it requires a lot of nasty clean-up and disentangling.... Several parts had been stashed away into `src/lib/test`, which are not really related: * the testrunner and testsuite builder * generic helper utilities * specialised test-support facilities, e.g. the EventLog This changeset introduces a new top-level test folder and a namespace `::test` Code from this folder is linked into a shared library `libtestsupport.so`, which resides in the linkage hierarchy between »Vessel« and »Vault«, yet is no longer part of the Lumiera application and only linked into the test-suite.
2026-03-06 21:34:20 +01:00
#include "test/run.hpp"
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
//#include "steam/play/diagnostic-output-slot.hpp"
BufferProvider: assess status and consider approach to OutputSlot (see #1395) The first round of the [ticket:1410 BufferProvider clean-up] is roughly complete. * a much cleaner diagnostic interface has been defined and implemented * this allowed to modernise the `DiagnosticBufferProvider_test` and the `BufferProviderProtocol_test` * the implementation scheme has been split in two realms * the old heap-memory based implementation has been re-arranged, so that the aforementioned tests are **green** again. Now is the point to draft a solution to get the interfaces of `BufferProvider` and `OutputSlot` aligned, so that the latter can expose its lifecycle through the former. Today, I have analysed various aspects and developed a pathway to get into that task, and next I will reshape the previously failed `OutputProxyProvider_test` into a prototype to validate this idea
2026-02-19 23:21:01 +01:00
#include "steam/engine/buffer-proxy-adaptor.hpp"
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
#include "steam/engine/test-rand-ontology.hpp"
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
#include "lib/meta/prop-builder.hpp"
Tests: build an link a test-support library This is something I wanted to clean-up since a very long time indeed, but always postponed it, since it requires a lot of nasty clean-up and disentangling.... Several parts had been stashed away into `src/lib/test`, which are not really related: * the testrunner and testsuite builder * generic helper utilities * specialised test-support facilities, e.g. the EventLog This changeset introduces a new top-level test folder and a namespace `::test` Code from this folder is linked into a shared library `libtestsupport.so`, which resides in the linkage hierarchy between »Vessel« and »Vault«, yet is no longer part of the Lumiera application and only linked into the test-suite.
2026-03-06 21:34:20 +01:00
#include "test/diagnostic-output.hpp" ////////////////////TODO
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
namespace steam {
namespace engine{
namespace test {
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
using lib::meta::PropBuilder;
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
/***************************************************************//**
Invocation: identify problems with buffer handling The ''design exercise'' started yesterday ran into a total rodadblock. And this is a good thing, as this unveils inconsistencies in our memory handling protocols * Buffer Provider Protocol * Output Slot Protocol The latter exposes a `BuffHandle`, which should be usable from within the Render Node code like any other regular buffer handle — which especially would require to ''delegate the lifecycle calls...'' So while this topic does not hinder us right now to proceed with a Node invocation in test setup, it must be addressed before we're able to deliver data into an actual OutputSlot. Created #1387 to track this topic...
2024-12-23 23:55:00 +01:00
* @test verify the design of OutputSlot and BufferProvider by
* implementing a delegating BufferProvider to expose
* output data buffers provided from _some implementation._
BufferProvider: assess status and consider approach to OutputSlot (see #1395) The first round of the [ticket:1410 BufferProvider clean-up] is roughly complete. * a much cleaner diagnostic interface has been defined and implemented * this allowed to modernise the `DiagnosticBufferProvider_test` and the `BufferProviderProtocol_test` * the implementation scheme has been split in two realms * the old heap-memory based implementation has been re-arranged, so that the aforementioned tests are **green** again. Now is the point to draft a solution to get the interfaces of `BufferProvider` and `OutputSlot` aligned, so that the latter can expose its lifecycle through the former. Today, I have analysed various aspects and developed a pathway to get into that task, and next I will reshape the previously failed `OutputProxyProvider_test` into a prototype to validate this idea
2026-02-19 23:21:01 +01:00
* @todo 2/2026 now using this setup for prototyping /////////////////////////////////////////////////TICKET #1415 : explore this design idea through prototyping
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
*/
class OutputProxyProvider_test : public Test
{
virtual void
clean-up: trifles
2025-06-07 23:59:57 +02:00
run (Arg)
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
{
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
BufferState state{NIL};
BufferProvider: experiment for callback configuration Now I have a working setup for a `BufferProxyAdaptor`. Unfortunately this is still confusingly complex. This is due to my intention to build a generic template, that can be configured with a policy to invoke arbitrary callbacks, whenever one of the passed-through buffers transitions through its lifecycle. * we need to configure the `BufferProviderSetup` to use our specific implementation classes * and the second one of these, our `BufferStore` implementation needs to invoke the callbacks
2026-02-22 23:39:10 +01:00
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
// setup with notification callback
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
BufferProxyAdaptor proxPro{PropBuilder()
.define (PROP_FIELD(on_lock), [&]{ state = LOCKED; })
.define (PROP_FIELD(on_emit), [&]{ state = EMITTED;})
.define (PROP_FIELD(on_release),[&]{ state = FREE; })
};
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
// Assuming some data block is »given«
seedRand();
size_t frameNr = defaultGen.u64();
TestFrame dataBlock (frameNr);
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
CHECK (dataBlock.isPristine());
CHECK (state == NIL);
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
BufferProvider: experiment for callback configuration Now I have a working setup for a `BufferProxyAdaptor`. Unfortunately this is still confusingly complex. This is due to my intention to build a generic template, that can be configured with a policy to invoke arbitrary callbacks, whenever one of the passed-through buffers transitions through its lifecycle. * we need to configure the `BufferProviderSetup` to use our specific implementation classes * and the second one of these, our `BufferStore` implementation needs to invoke the callbacks
2026-02-22 23:39:10 +01:00
BuffHandle handle = proxPro.lockBuffer (dataBlock);
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
CHECK (state == LOCKED);
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
// Now a »client« can do awful things to the buffer...
CHECK (handle.isValid());
auto& data = handle.accessAs<TestFrame>();
uint64_t param = defaultGen.u64();
Invocation: reorg namespace for TestRandOntology The namespace `steam::engine::test::ont` will hold some typical definitions for the fake „media processing library“ — to be used for validating aspects of mapping and binding.
2025-01-06 22:00:29 +01:00
ont::manipulateFrame (&data, &data, param);
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
HashVal check = data.getChecksum();
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
// »client« is done...
handle.emit();
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
CHECK (state == EMITTED);
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
// end usage cycle
handle.release();
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
CHECK (state == FREE);
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
CHECK (not handle.isValid());
CHECK (not dataBlock.isPristine());
CHECK ( dataBlock.isValid());
BufferProvider: document the new design and use it for the prototype Explored further aspects of this new design; as an aside, I tried to build a Concept to describe the policy, which howerer turned out to be much more challenging than expected. Lastly, I could now complete the prototype of `BufferProxyAdaptor`
2026-02-26 23:25:07 +01:00
CHECK (check == dataBlock.getChecksum());
Invocation: investigate forwarding an output data block This investigation started out as solving an already solved problem... I'll continue this as a design exercise non the less. __Some explanation__: To achieve the goal of invoking a Node end-to-end, the gap between the `Port` API, the `ProcNode` API and the `RenderInvocation` must be closed. This leads to questions of API design: ''what core operation should the `ProcNode` API expose?'' * is `ProcNode` just a forwarding / delegating container and becoming redundant? * or does the API rather move in the direction of an ''Exit Node''? This leads to the question how the opened `OutputSlot` can be exposed as a `BuffHandle` to allow to set off the recursive Node invocation. As it turns out, the onerous for this step lies on the actual `OutputSlot` implementation, since the API and output protocol already requires to expose a `BuffHandle`. Yet there is no "real" implementation available, just a Mock setup based on `DiagnosticBufferProvider`, which obviously can just be passed-through. Which leaves me with mixed feelings. For one it is conveninent to skip this topic for now, but on the other hand the design of `BufferProvider` does not seem well suited for such an proxying task. Thus I decided to explore this aspect in the form of a prototyping test....
2024-12-22 22:31:05 +01:00
}
};
/** Register this test class... */
LAUNCHER (OutputProxyProvider_test, "unit play");
}}} // namespace steam::play::test
Reference in a new issue Copy permalink