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

89 lines
2.9 KiB
C++
Raw Permalink 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
*/
#include "lib/test/run.hpp"
//#include "steam/play/diagnostic-output-slot.hpp"
#include "steam/engine/buffer-proxy-provider.hpp"
#include "steam/engine/test-rand-ontology.hpp"
namespace steam {
namespace engine{
namespace test {
/***************************************************************//**
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._
* @todo WIP-WIP 12/2024 this turned out to be impossible,
* due to inconsistencies in the default implementation. /////////////////////////////////////////////TICKET #1387 : need to consolidate BufferProvider default implementation
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
{
size_t seenID{0};
BufferState lastState{NIL};
auto listener = [&](size_t id, BufferState state)
{
seenID = id;
lastState = state;
};
// setup with notification callback
BufferProxyProvider proxPro{listener};
// Assuming some data block is »given«
seedRand();
TestFrame::reseed();
size_t frameNr = defaultGen.u64();
TestFrame dataBlock (frameNr);
CHECK ( dataBlock.isPristine());
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
BuffHandle handle = proxPro.lockBuffer (dataBlock); ///////////////////////////////////////////////TICKET #1387 : unable to implement this
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);
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();
// end usage cycle
handle.release();
CHECK (not handle.isValid());
CHECK (not dataBlock.isPristine());
CHECK ( dataBlock.isValid());
}
};
/** Register this test class... */
LAUNCHER (OutputProxyProvider_test, "unit play");
}}} // namespace steam::play::test
Reference in a new issue Copy permalink