BufferProvider: aiming at a simplified engine configuration

While this topic is only tangentially related to the problems
with the »Buffer Provider Protocol«, the configuration of service instances
is relevant, insofar it provides a configuration point for unit testing.

The structure of the `EngineCtx` was created as a placeholder, to get those
issues out of the way while drafting the render node code; in its current
form it is clearly both to complicated and inflexible.

My intention is to merge the `EngineCtx::Facilities`, and to prefer
configuration of more elaborate setup by subclasses.
This commit is contained in:
Fischlurch 2026-01-28 02:22:33 +01:00
parent d00992ff70
commit 559bb17c17
3 changed files with 15 additions and 10 deletions

View file

@ -1,5 +1,5 @@
/*
EngineCtxFacilities - Implementation of global render engine operational services
EngineCtx - Base implementation of global render engine operational services
Copyright (C)
2024, Hermann Vosseler <Ichthyostega@web.de>
@ -12,12 +12,13 @@
* *****************************************************************/
/** @file engine-ctx-facilities.hpp
** Implementation parts of render engine operational services.
** @warning as of 10/2024 a preliminary integration of Render-Engine underway ////////////////////////////////////////TICKET #1367
/** @file engine-ctx.cpp
** Base implementation of render engine operational service configuration.
** @warning as of 1/2026 a preliminary integration of Render-Engine underway ////////////////////////////////////////TICKET #1367
*/
#include "steam/engine/engine-ctx.hpp"
#include "steam/engine/engine-ctx-facilities.hpp"
#include "steam/engine/tracking-heap-block-provider.hpp"

View file

@ -19,6 +19,9 @@
** The EngineCtx itself is meant to be [dependency injected](\ref lib::Depend), so that
** tests can use suitably adapted variants for verifications. The default instantiation
** provides a naive self-contained implementation suitable for demonstration and test.
** For productive use within the Lumiera Render Engine, a much more elaborate setup
** is necessary, including setup of a frame cache, and of timing strategies; these
** are configured as part of starting the steam::engine::RenderEnvironment.
** @todo who is responsible for setup of the services for the actual render engine?
** Might be closely related to brining up façade interfaces.
** @todo WIP-WIP 1/2026 provide a default implementation for test
@ -26,7 +29,7 @@
** production variant of the services...
**
** @see engine-ctx-test.cpp
** @see engine-ctx-facilities.hpp implementation
** @see engine-ctx.cpp base implementation
** @see buffer-provider.hpp
** @see buffhandle.hpp
*/

View file

@ -1,5 +1,5 @@
/*
ENGINE-CTX-FACILITIES.hpp - Implementation of global render engine operational services
ENGINE-FACILITIES.hpp - Access and coordination of global render engine operational services
Copyright (C)
2024, Hermann Vosseler <Ichthyostega@web.de>
@ -11,7 +11,7 @@
*/
/** @file engine-ctx-facilities.hpp
/** @file engine-facilities.hpp
** Implementation of render engine operational configuration and services.
** Without further setup, [dependency injection](\ref depend.hpp) will establish a
** minimalistic default instantiation of these services, sufficient for demonstration
@ -19,14 +19,15 @@
** created and managed actively.
** @todo and we'll have yet to »figure out« what specifically to do for these
** services and how to start an active render engine for productive use.
** @todo WIP-WIP 10/2024 strive at first complete prototypical engine usage ////////////////////////////////////////TICKET #1367
** @deprecated 1/2026 I'm unhappy with this convoluted structure;
** my intention is to fuse that with the engine-ctx.cpp implementation.
**
** @see engine-ctx.hpp
** @see weaving-pattern-builder.hpp
*/
#ifndef STEAM_ENGINE_ENGINE_CTX_FACILITIES_H
#define STEAM_ENGINE_ENGINE_CTX_FACILITIES_H
#ifndef STEAM_ENGINE_ENGINE_FACILITIES_H
#define STEAM_ENGINE_ENGINE_FACILITIES_H
#include "steam/engine/engine-ctx.hpp"