reassess design of render job deadline planning

[Ichthyostega]

As Lumiera Architect,
I want to reconcile multiple attempts towards a framework for tree evaluation,
to avoid breeding unnecessarily complex and hard to maintain code.

a concern of software craftsmanship

Originated by a prevalence of querying and evaluation, which seems to be a distinct trait of Lumiera, there is a recurring pattern of demand-driven tree expansion, performed under constrained memory usage, and sometimes combined with backtracking. Over the course of the last years, two different usages of this evaluation pattern crystallised into a generic library framework. The first attempt, spurred by the implementation of render job planning in the Engine, was based on the Monad Pattern touted by functional programming, and — as seems to happen commonly with this approach — leads at usage site to code, which can be described as somewhat cool and completely bewildering for anyone without deep mathematical inclinations. On next occasion, some years later in the context of the GUI, a different design approach was taken, this time relegating the monad-style expansion to be a mere special case embedded into a processing pipeline. Further reuse of this second framework seems to imply that this design fosters clearer code at usage site and thus proves itself as more successful as means of abstraction.

So we are now facing the situation, where the exiting implementation of render job planning could immediately be taken into practical use, but shows signs of misaligned design and unnecessary complexity. Given the barrier created by any kind of elevated abstraction, combined with the further complexities incurred by the various render- and non-standard playback modes, there is the danger of breeding impenetrable code, entangled with accidental complexity and blocking further evolution in a crucial part of the system.

Acceptance Criteria

• a critical re-assessment of the exiting solution for render job planning has been carried out
• either, the implementation has been lifted to build upon the newer TreeExplorer or a distinctive trait has been isolated which prevents such a subsumption

[Ichthyostega]

Starting with this one; it poses a good opportunity to get involved into core render engine design...

[Ichthyostega <prg@…>]

In d109f5e/Lumiera:

bye bye Monad (closes #1276)

after completing the recent clean-up and refactoring work,
the monad based framework for recursive tree expansion
can be abandoned and retracted.

This approach from functional programming leads to code,
which is cool to write yet hard to understand.

A second design attempt was based on the pipeline and decorator pattern
and integrates the monadic expansion as a special case, used here to
discover the prerequisites for a render job. This turned out to be
more effective and prolific and became standard for several exploring
and backtracking algorithms in Lumiera.

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin