Commit graph

4 commits

Author SHA1 Message Date
ace20660aa BufferProvider: analyse the existing API
- write some documentation
 - identify some add-on API that must be retracted
 - consider further how to disentangle ''diagnostics'' and ''implementation''
2026-02-12 05:06:13 +01:00
9c5eb11b0c BufferProvider: switch to the new implementation structure
More or less forcibly squeeze all the existing implementation
into the new basic structure with two separate »pillars«

**Breakages**
 - existing code expected the `BufferStore` to transition to ''locked'' state
 - existing code expected `provideLockedBuffer(typeID)` to tail-call the
   `buildHandle()` function of the enclosing `BufferProvider` base implementation
 - various diagnostic usages bypassed the official APIs and called directly
   into the implementation. This is no longer possible; rather, `DiagnosticBufferProvider`
   needs to provide additional diagnostic API to suit those purposes
2026-02-11 02:13:43 +01:00
1ebefbe36e BufferProvider: identify usages of the default BufferProvider
The prototype implementations of BuferProvider and OutputSlot are confusing;
in-depth analysis shows that this is related to intermingling use
of test instrumentation and features of a prototypical default.

To get anywhere with the existing code, it seems we'd need to split off
the test instrumentation (i.e. `DiagnosticBufferProvider`) altogether,
even if this causes duplication of implementation code. Many years ago,
when first implementing this prototype, I had no clear idea what the usage
in the Render Engine entails, yet I noticed that some basic buffer »tracking«
could be used as implementation primitive to simplify the prototyping work.
This might be one of the reasons, why the "code behind" in the protocol
implementations both in `BufferProvider` and `OutputSlot` became so strongly
tangled, so that I way unable to make both protocols orthogonally composable.
2026-02-09 00:59:35 +01:00
256c446705 BufferProvider: consider to disentangle diagnostics and default implementation
The implementation code for `DiagnosticOutputProvider` and `TrackingHeapBlockProvider`
look very confusing and tangled. It seems, instrumentation for tests
got mixed up with the effort to provide a simplistic prototype implementation.

What we need foremost here is the latter; most tests that import the
DiagnosticOutputProvider do not even use any instrumentation....
2026-02-09 00:59:30 +01:00
Renamed from tests/core/steam/engine/tracking-heap-block-provider-test.cpp (Browse further)