lumiera_documentation/tests/core/steam
Ichthyostega 3d6e2fea75 BufferProvider: reconsider and rearrange the public API
In the end I refrained from applying most of the changes I had intended.
I am aware that `BufferProvider` is still quite a massive structure,
yet with the implementation refactorings done thus far, it seems
to be reasonably clear and self-contained now.

It would be possible to totally overthrow the grown structure and
expose only the two handles (BuffDescr and BuffHandle), together with
a factory function, but I cannot see how this would help to make the
code clearer and more approachable. Maybe it would make the usage
more obvious from the client's perspective — yet, to be honest,
there are not ''that much clients'' to justify such a move.

Furthermore, the implementation is far from finished: for both of
the back-end lines, a fully production-strength implementation
must be created, that is able to operate in a highly concurrent
environment; very likely some lock-free messaging and hand-over
between threads will become necessary, adding to the complexity.

Thus it seems better to note the ''design critique'', but to
postpone any further refactorings to a point where we can watch
a fully developed Render Engine under production load.
2026-02-16 20:50:04 +01:00
..
asset Upgrade: simplify comparisons 2025-07-04 03:37:54 +02:00
control Upgrade: down with typename!! 2025-07-06 01:19:08 +02:00
engine BufferProvider: reorder validity handle validity checks 2026-02-16 01:00:12 +01:00
fixture clean-up: trifles 2025-06-07 23:59:57 +02:00
mobject Upgrade: down with typename!! 2025-07-06 01:19:08 +02:00
play BufferProvider: reconsider and rearrange the public API 2026-02-16 20:50:04 +01:00
render-segment-test.cpp clean-up: trifles 2025-06-07 23:59:57 +02:00