BufferProvider: rename OutputSlot implementation parts
The state of connectedness is represented as class, which actually is a three step deep hierarchy. This design seems plausible, since we get - an interface visible for clients (`Allocation`) - an internal interface - the actual implementation, templated to the actual connection At least we can try to choose names that better indicate these three related levels.
This commit is contained in:
parent
259d0a5728
commit
705bd3d2e0
6 changed files with 72 additions and 22 deletions
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
DIAGNOSTIC-BUFFER-PROVIDER.hpp - helper for testing against the BufferProvider interf,ttace
|
||||
DIAGNOSTIC-BUFFER-PROVIDER.hpp - helper for testing against the BufferProvider interface
|
||||
|
||||
Copyright (C)
|
||||
2011,2026 Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
|
|||
49
src/vault/out/diagnostic-output-slot.cpp
Normal file
49
src/vault/out/diagnostic-output-slot.cpp
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
/*
|
||||
DiagnosticOutputSlot - helper for testing against the OutputSlot interface
|
||||
|
||||
Copyright (C)
|
||||
2026, 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.
|
||||
|
||||
* *****************************************************************/
|
||||
|
||||
|
||||
/** @file diagnostic-output-slot.cpp
|
||||
** Internal implementation parts of a state-tracking dummy implementation
|
||||
** of the OutputSlot interface and framework.
|
||||
*/
|
||||
|
||||
|
||||
#include "lib/error.hpp"
|
||||
#include "vault/out/diagnostic-output-slot.hpp"
|
||||
//#include "vault/out/output-slot-connection.hpp"
|
||||
|
||||
//#include <vector>
|
||||
|
||||
|
||||
namespace vault {
|
||||
namespace out {
|
||||
namespace err = lumiera::error;
|
||||
|
||||
// using std::vector;
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
// OutputSlot::~OutputSlot() { } // emit VTables here....
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/** */
|
||||
|
||||
|
||||
|
||||
|
||||
}} // namespace vault::out
|
||||
|
|
@ -62,6 +62,7 @@ namespace out {
|
|||
using vault::mem::BuffDescr;
|
||||
|
||||
using std::shared_ptr;
|
||||
using std::make_unique;
|
||||
|
||||
using PGrid = lib::P<lib::time::Grid>;
|
||||
|
||||
|
|
@ -362,9 +363,9 @@ namespace out {
|
|||
* thus allowing to verify the handling of individual buffers
|
||||
*/
|
||||
class SimulatedOutputSequences
|
||||
: public ConnectionManager<TrackingInMemoryBlockSequence>
|
||||
: public AllocStateHub<TrackingInMemoryBlockSequence>
|
||||
{
|
||||
typedef ConnectionManager<TrackingInMemoryBlockSequence> _Base;
|
||||
typedef AllocStateHub<TrackingInMemoryBlockSequence> _Base;
|
||||
|
||||
void
|
||||
buildConnection(ConnectionStorage storage)
|
||||
|
|
@ -385,10 +386,10 @@ namespace out {
|
|||
|
||||
|
||||
/** hook into the OutputSlot frontend */
|
||||
ConnectionState*
|
||||
unique_ptr<AllocState>
|
||||
buildState()
|
||||
{
|
||||
return new SimulatedOutputSequences(
|
||||
return make_unique<SimulatedOutputSequences> (
|
||||
getOutputChannelCount());
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
** The OutputSlot concept helps to decouple the render engine implementation from the details
|
||||
** of handling external output connections. For this to work, a concrete implementation of such
|
||||
** an external output needs to integrate with the generic OutputSlot frontend, as used by the
|
||||
** engine. This generic frontend uses a PImpl, pointing to a ConnectionState object, which embodies
|
||||
** engine. This generic frontend uses a PImpl, pointing to a AllocState object, which embodies
|
||||
** the actual implementation. Moreover, this actual implementation is free to use specifically crafted
|
||||
** OutputSlot::Connection elements to handle the ongoing output for individual channels. The latter
|
||||
** thus becomes the central implementation side API for providing actual output capabilities.
|
||||
|
|
@ -75,7 +75,7 @@ namespace out {
|
|||
* Actually, this extension point towards the implementation
|
||||
* of the actual output handling carries the core API of OutputSlot.
|
||||
* Thus, the task of actually implementing an OutputSlot boils down
|
||||
* to implementing this interface and providing a ConnectionState.
|
||||
* to implementing this interface and providing a AllocState.
|
||||
* - `lock()` announces this FrameID and the corresponding buffer
|
||||
* to be in exclusive use by the client from now on
|
||||
* - `transfer()` ends the client sided processing and initiates
|
||||
|
|
@ -104,17 +104,17 @@ namespace out {
|
|||
|
||||
/**
|
||||
* Extension point for Implementation.
|
||||
* The ConnectionState is where the concrete output
|
||||
* The AllocState is where the concrete output
|
||||
* handling implementation is expected to reside.
|
||||
* OutputSlot is a frontend and accesses
|
||||
* ConnectionState in the way of a PImpl.
|
||||
* AllocState in the way of a PImpl.
|
||||
*/
|
||||
class OutputSlot::ConnectionState
|
||||
class OutputSlot::AllocState
|
||||
: public OutputSlot::Allocation
|
||||
, util::NonCopyable
|
||||
{
|
||||
public:
|
||||
virtual ~ConnectionState() { }
|
||||
virtual ~AllocState() { }
|
||||
|
||||
virtual Connection& access (uint) const =0;
|
||||
};
|
||||
|
|
@ -130,7 +130,7 @@ namespace out {
|
|||
{
|
||||
protected:
|
||||
template<class CON>
|
||||
class ConnectionManager;
|
||||
class AllocStateHub;
|
||||
};
|
||||
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ namespace out {
|
|||
* representing the "active points" in several media channels
|
||||
* connected through this OutputSlot. These Connection subclasses
|
||||
* are what is referenced by the DataSink smart-ptrs handed out
|
||||
* to the client code. As ConnectionState implements the Allocation
|
||||
* to the client code. As AllocState implements the Allocation
|
||||
* API, it has the liability to create these DataSink smart-ptrs,
|
||||
* which means to wire them appropriately and also provide an
|
||||
* deleter function (here #shutdownConnection) to be invoked
|
||||
|
|
@ -152,8 +152,8 @@ namespace out {
|
|||
* manages a collection of active Connection subclass objects.
|
||||
*/
|
||||
template<class CON>
|
||||
class OutputSlotImplBase::ConnectionManager
|
||||
: public OutputSlot::ConnectionState
|
||||
class OutputSlotImplBase::AllocStateHub
|
||||
: public OutputSlot::AllocState
|
||||
{
|
||||
typedef lib::ScopedCollection<CON> Connections;
|
||||
typedef OutputSlot::OpenedSinks OpenedSinks;
|
||||
|
|
@ -195,7 +195,7 @@ namespace out {
|
|||
init() ///< derived classes need to invoke this to build the actual connections
|
||||
{
|
||||
//////////////////////////TICKET #878 really build all at once? or on demand?
|
||||
connections_.populate_by (&ConnectionManager::buildConnection, this);
|
||||
connections_.populate_by (&AllocStateHub::buildConnection, this);
|
||||
}
|
||||
|
||||
using ConnectionStorage = Connections::ElementHolder&;
|
||||
|
|
@ -205,13 +205,13 @@ namespace out {
|
|||
virtual void buildConnection(ConnectionStorage) =0;
|
||||
|
||||
|
||||
ConnectionManager(uint numChannels)
|
||||
AllocStateHub(uint numChannels)
|
||||
: connections_(numChannels)
|
||||
{ }
|
||||
|
||||
public:
|
||||
virtual
|
||||
~ConnectionManager()
|
||||
~AllocStateHub()
|
||||
{ }
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ namespace out {
|
|||
if (not isFree())
|
||||
throw err::Logic ("Attempt to open/allocate an OutputSlot already in use.");
|
||||
|
||||
state_.reset (this->buildState());
|
||||
state_ = this->buildState();
|
||||
return *state_;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -105,14 +105,14 @@ namespace out {
|
|||
protected:
|
||||
|
||||
/** active connections through this OutputSlot */
|
||||
class ConnectionState;
|
||||
class AllocState;
|
||||
|
||||
unique_ptr<ConnectionState> state_;
|
||||
unique_ptr<AllocState> state_;
|
||||
|
||||
/** build the \em connected state,
|
||||
* based on the existing configuration
|
||||
* within this concrete OutputSlot */
|
||||
virtual ConnectionState* buildState() =0;
|
||||
virtual unique_ptr<AllocState> buildState() =0;
|
||||
|
||||
|
||||
public:
|
||||
|
|
|
|||
Loading…
Reference in a new issue