Changeset 44b3dbe in Lumiera

Timestamp:

2026-04-12T23:08:48Z (5 weeks ago)

Author:

Ichthyostega <prg@…>

Branches:

dev/play

Children:

4dc6885

Parents:

ce5f7d5

git-author:

Ichthyostega <prg@…> (12/04/26 21:53:07)

git-committer:

Ichthyostega <prg@…> (12/04/26 23:08:48)

Message:

BufferProvider: investigate and fix broken NodeDevel_test

The actual mystery, that could not be clarified,
is why that test did pass previously. Because it was
always broken, insofar it pretended that the output buffer
does hold a valid test frame, while in fact the buffer is
just newly allocated.

The deeper reason behind this mismatch lies in the concept of
in-place processing — which is a very obvious, nullary optimisation,
and thus we want our engine to be in-place capable in the long run.
Which explains why I did write the dummy-test operations with in-place
processing in mind. Yet the actual version of the render engine leaves
out a lot of future improvements, amongst others the in-place processing.

This implies that — at least at the moment — it is clearly the responsibility
of the processing function to prepare the output buffer, in cases where such
preparation is necessary (and this applies in the case of TestFrame,
which needs to be primed with a valid header mark)

This change touches on another unsolved problem in the TestDomainOntology:
we need a mechanism to allow the generic builder front-end to set
specific configuration for some kind of processing. Generally speaking,
such things are possible in C++, yet somewhat tricky — and thus I postponed
that aspect and just included a configuration variant, hard-coded for the moment.

(No files)