As a consequence of preceding experiments..
* I'll stick to the structure of the BufferProvider front-end interface
* also the »code behind« will remain there; a purely abstract API has no merit here
* however, the ''setup'' of the actual implementation will move into a derived class
* this derived scope class, `BufferProviderSetup` will house two implementation classes
* these two, now named `Stage` and `Store` provide the base implementation
for the two "pillars" of the implementation
Admitted, this structure is now much more elaborate, but it's the only path forward
I'm currently able to come up in order to disentangle the existing implementation mess...
The outward interface has stood the test of time quite well.
But the back-side towards the implementation is a tangled mess,
presumably due to being developed from prototyping code: the
actual implementation is completely overgrown by diagnostics
and test instrumentation, since running in unit test setup
was the only actual usage of this code ever since.
My first attempt with decomposing into a decorator-chain failed.
Thus the new line of attack is to introduce two implementation
pillars right from top-level
- `BufferStage` : the state and metadata handling
- `BufferStore` : the storage backend
These are defined as nested interfaces, and the further refactoring
starts with subclassing everything, nested as it is.
The intention is to build the tracking functionality from scratch,
while wrapping the old implementation as delegate. Hopefully this allows
to reduce the complexity of the existing implementation step by step,
until I'm ''able to grasp what this implementation does''.
This old implementation works, but is highly problematic code.
The Git history shows that I had already problems to understand this code
while building the DiagnosticOutputSlot, one year later.
To my defense, in both cases (2011 and 2012), I had no clear idea yet
how the processing within the engine would work, and thus I considered
that Buffer Type registry a mere implementation detail, that can be
lumped into the »code behind«.
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.
`EngineCtx` is considered merely an access front-end now;
After some analysis of existing code, it seems the RenderEnvironment
is the most appropriate framework to configure the global engine services
and thus to ''boot the Render Engine''.
The access to the `EngineCtx` is tricky, because of the requirements
* it will be dependency-injected into the internals of the Render Nodes
* excessive indirection should be avioded; preferrably the actual
code in the render pipeline sees a pointer (coded as language reference)
which directly refers to the buffer and cache manager.
* but on the other hand, we want configurability; simple tests shall
access "the buffer manager" without much ado, while the actual
render engine obviously has a life cycle and needs an administrative
access to the various global implementation facilities
* this both together implies some kind of ''virtual constructor''
* and since such a pattern can not be implemented in C++ with simple
inheritance (because the base constructor does not "see" the actual
implementation type at the time when it's invoked), the solution
is to rely on a second indirection through our dependency-injection
framework: thus the setup of the actual implementation is what
can be configured flexibly, and overridden by mock implementation
for some test cases
It seems evident that the the problems with the existing BufferProvider implementation
are rooted in a lack of understanding of the actual usage situation at that time(2011).
This caused a »hexagonal design«, i.e. something entirely driven by uint testing
for the sake of unit testing.
So to identify the unsuitable decisions, some degree of deductive work is necessary,
based on our much better understanding of the Render Engine.
A crucial challenge is that buffer management must perform well
within a massively concurrent environment, and do so without excessive latency.
This picks up the work for [ticket:1395 resolve integration of BufferProvider with DataSink (#1395)]:
Almost a year ago, before the long hiatus due to important general clean-up
and maintenance work, and the research regarding Video output —
a discrepancy was discovered between the »Buffer Provider Protocol«
and the »Output Slot Protocol«. This mismatch prevents us from building
a simple preliminary `BufferProvider` to be used for the engine integration
as part of the [ticket:1228 »Playback Vertical Slice«].
After re-establisihing the work context, I have read through the new
Render Node code built last year, and distilled the sequence of
buffer management operations that actually happen during a recursive
`pull()` call. With this kowledge, I am now able to fill in the
''standard case for rendering'' — which I was unable to formulate
during the first attempt of building the Render Engine in 2011.
__Next Steps__: Redesign of the standard implementation base of the
`BufferProvider` to prepare for a massively concurrent usage.
...some notes to my personal mindmap.
- Webserver OS upgrade
- Clean-up of services and cronjobs
- Apache configuration updated and fine-tuned
- deployed Anubis to protect against overload by AI-scraper bots
Hereby I introduce a ''Development Status'' page, where the
current phase of the release cycle can be marked and similar
status information is published. This page also includes
the Changelog (from the file NEWS). Since updates must
be checked into Git and then pushed to our website,
such status marks are documented in the history.
Some notes regarding the phases of the Release cycle
were also added to the Release checklist.
+ some additional links resources and documentation tweaks
- comb through the Website, starting at the frontpage
- add a **news** entry to confirm this major upgrade step (C++23)
- improve the wording in various overview pages
- adapt the ''release checklist'' to align it with **git-flow**
- reorganise the image folder(s) on the website
- the animated beating heart is back ;-)
On the Website, there is a set of interconnected pages related
to compiling from source, the Debian package and our DEB depot.
Although these pages have always been superficially kept up-to-date,
the overall presentation feels dated and generally not well organized.
During the last weeks, I have almost entirely rewritten all those pages,
added information about the (now reworked) DEB package, explained the
alternate ways to build from a Debian source package (notably the
`mk-build-deps` for handling the build dependencies, which effectively
the only method which always worked during the last years, since our
DEB package was totally outdated)
Furthermore, I have tested most of the build steps with the current
source trees, repositories and package definition, and finally I
have also updated and polished the front-page of our DEB-Depot
(-> see commit on the depot-Branch)
Wheew ... quite some work done!
Many versions enforced with this changeset are chosen such
as to support Ubuntu/Noble (24.04) and otherwise use versions
reasonably close to Debian-Trixie (≙reference-platform)
Since we now require a fairly modern compiler for C++23,
I have added now an explicit version check, which however
is performed only if the defined compiler is named `g++*`
Furthermore, I combed through all of our build tutorials and documentation pages
and updated a lot of information regarding dependencies and build practices...
Many years ago, I integrated the IconSvgRenderer (written by Joel Holdsworth)
directly into the SCons build by means of a custom builder with an ''emitter function''.
The build as such works fine and automatically determines which icons can be
generated from a given SVG source. However, those SVG icons tend to be rebuilt
very frequently, even while none of the SVG sources has changed.
Basically this was more of an annoyance, since we have now about 15 icons
and the rendering is really fast ... it is just ugly, especially on
incremental builds (and it could become a problem once we have a
massive amount of graphics to process.
So I took the opportunity to take close look now, since I am doing
uninspiring clean-up work since several weeks now. But that problem
turned out to be quite insidious and hard to spot.
First, AI set me off into a completely wrong angle, since it is ''not''
caused by a missing string representation of the custom Action class.
However, from there I went to watching the target checks with the debugger,
and this eventually got me to realise, that SCons mistakenly detects
a change in the Executor / the Action class.
The root cause is, that we invoke Python code from an external Module,
IconSvgRenderer.py, and this is »materialised« by SCons automatically
into a string representation, which includes memory addresses of functions
in that module. And that yields a signature, that is, quite obviously,
not stable, even while you end up sometimes with loading the code to
the same memory location.
As a solution / workaround, we now subclass the standard implementation
from SCons and override the signature function; instead of fingerprinting
the binary code, we just compute a MD5 over the python source file,
which can be easily achieved with the help of the File-Node from SCons.
Essential resources:
https://scons.org/doc/4.8.0/HTML/scons-user.html#chap-builders-writing
...and the Reference / Manpage of SCons
https://scons.org/doc/4.8.0/HTML/scons-man.html#action_objects
SCons/Action.py
SCons/Node/__init__.py
* Simplify some constructs from the Python-3 migration
* update copyright, since I did maintain the SCons build continuosly
* remove unused method from Buildhelper
Furthermore, the documentation page for our build system
https://lumiera.org/documentation/technical/build/SCons.html
has been reworked, to add a synopsis, some further background
information about the internal structure of SCons and about
the specific conventions and definitions used for Lumiera
Lumiera is built such that it can be invoked from a ''bundle directory''
without the need to install it into the system; this requires to perform
a relative lookup of shared modules loaded as dependencies.
Since Lumiera has a layered architecture, and each layer is built into a shared object,
we get transitive dependencies and thus transitive relative lookup.
There was a bug in binutils 2.23, which caused that transitive relative lookup to fail.
* as of 2025, Debian/Trixie is defined as ''Reference Platform''
* in Trixie the binutils version is v2.44-3
* after removing the workaround, Lumiera and all tests can be launched
* thus ''considering this workaround as obsolete now''
This is a Debian policy, which collides with the default behaviour
of GCC rsp. the plattform linker. The latter creates all ELF files as
executable, possibly because some platforms require that, and also
because some libraries provide a main() function for diagnostics.
The argument by the Debian people is that most libraries don't provide
such a main() and that this is an esoteric feature which should not be
supported by default.
We can fix that in our SCons build, since we use a specialised Builder
to also define the install targets systematically; it suffices to add
a post-action to these install targets for shared objects.
Note: currently Debian/Trixie provides SCons 4.8, but v4.10 will provide
a shorthand notation with the env.Chmod Action factory.
Some recherche regarding the requirements and conditions of the GPL
made it clear that we are obliged to have at least an summary statement
of all authors and the years of their contributions embedded somewhere
in the source itself. The Git history alone is not sufficient to fulfil
this requirement, since a code base could be packaged as Tarball
and passed-on outside of any Git repository.
Thus I propose the following policy
- add yourself to the copyright header whenever you made
some ''significant'' contribution to a code file
- maintain a list of relevant authors at top-level,
indicating a time range of their contribution
- use the same information also in the debian/copyright (DEB package)
- clarify in the LICENSE that authorship can be extracted from Git
__Remark__: Anton Yakovlev made a single code contribution in 2009 (87e528bd),
which was never used anywhere and removed as part of a general clean-up in 2023.
Thus I do not list him as a code author, but he is mentioned in credits.txt
- use a current copy of the GPL2 text, downloaded from fsf.org
- reformat the AUTHORS and get rid of the table formatting
- Stackoverflow has upgraded its Subscriber Content license to CC-By-SA 4.0
A handwritten changelog is considered important and
helps to single out the overall relevant achievements.
Following a proposal from the Debian policy, this summary
of development steps will now be maintained in the NEWS file.
It will be marked with the version number of Lumiera.
...and split-out the description of preview-releases,
since that rather belongs into some kind of changelog (NEWS).
Furthermore, check the links to the build dependencies
See corresponding commit in the website repository.
- Verified all authors via Git
- simplify the list and group by core/contributors
- list only significant contributors here
__Note__: the page "project/contributors" on the website
contains a much more extensive list with all helpers,
casual contributors and concept discussion participants
The XDG Desktop spec is accepted universally, and thus
the old Debian-specific 'menu' system is deprecated and
no longer engaged automatically.
See: https://lists.debian.org/debian-devel-announce/2015/09/msg00000.html
Thus we'll now provide a Desktop file and install that already from out
SCons build system, together with a suitable variation of the Lumiera icon.
TODO: not sure if everything was done the correct way
* do we need to ''register'' the new file in some way (preinst script?)
* the menu entry shows up, but not the icon
* but if we put an absolute path for the lumiera.svg into the desktop file, it shows up
Remark: in later experiments with package building,
the menu entry and the icon showed up in the menu.
Not sure if this requires a reboot or some similar
trigger (like restart of the destkop)
...funny enough I never noticed this obvious mistake,
since I never install software directly into my system,
while the DEB-build does not use absolute paths...
Solution:
* SCons has this speical convention that a path prefixed with '#'
is resolved relative to the root of the build (where the SConstruct resides)
* now we apply this automatically to the two relevant settings
** INSTALLDIR
** TARGDIR
* but only (conditionally) if the configured path is relative, not absolute
As a consequence, most other hard-coded usages of the '#'-prefix can then be dropped
Yes, I know...
Programmers absolutely LOVE to sneak-in various nifty toggles via environment.
Yet this is an anti-pattern!
And, by extension of that verdict, a "build interface" which relies
on the implicit convention that some magical variables are set,
is **not a proper interface** but a hack.
Thus we abandon that bad practice and handle the build in a clean and explicit way.
* the DEB-Build in `debian/rules` now invokes SCons explicitly, passing arguments
* the Lumiera Build-System is FSH aware and knows the proper installation locations
* the setup of the application uses a setup configuration, shipped with the package
* there is no need to ''compile-in any configuration''
** `LUMIERA_PLUGIN_PATH` is obsolete and unused since several years now
** `LUMIERA_CONFIG_PATH` was never used at all
** consequently, we also do not need `PKGLIBDIR` and `PKGDATADIR`
...this bug was spotted as the test failed reproducibly
when built with `-fstack-protector-strong` — which adds
additional "canary" markers to some kinds of problematic
stack storage; this seemed to have the effect that now
the second test uses exactly the same location as the
preceding test, and thus finds valid data in the newly
created work buffers.
There is no reason for using uninitialised storage in this
test (I can recall that I wanted to build a generic helper
and intended to use that as ''virtual overlay'' over existing
memory — but that usage never took place, and the `struct Buffer`
is not a general-purpose tool now, but only made for this
specific test. Thus memory can be easily zero-initialised.
Turns out that in practice there will be (at least temporarily)
some version-tags including a suffix: the RC-versions!
Now there is the special twist, that Git does not allow '~' in Tag names,
and thus `git-buildpackage` introduced an additional layer of translation.
So we are forced to revert that translation, which is possible,
since the basic Debian version syntax disallows '_' in version numbers
(because '_' is used to separate the package name from the version number).
It seems prudent to implement that as an preprocessing step
and thus keep it out of the regular version number syntax.
Furthermore we need the ability to handle existing suffixes,
which (as we know now) can be picked up from the Git history.
* my decision is to allow both pass-through and suppressing them
* use `--suffix=False` to suppress / remove any existing suffix
* the latter now allows us also to automate the setting of
the final Release version
Based on the additional insight gained through the FrOSCon talk,
an attempt was made to investigate and fix the garbled display of the
docking panel header directly above our VideoDisplayWidget.
However, that turned out to be a problem with insufficeint support
of the XVideo standard with my (very old, 2011) NVidia graphic card.
Indeed, the hardware+software stack needs to support this Auto-Keying
extension of XVideo, so that the video display can be integrated
seamlessly into the rest of the UI. In my case, the driver seemingly
just fills the complete XWindow with the key-marker and thus the
decorations of the docking panel, which happens to use the same XWindow,
will just not be flushed to the display.
This unsuccessful research indicates that upholding support for XVideo
could become problematic...
- reorganise the navigation tab structure
- place all further index lists into a common "Index" tab
- include a list of concepts
- remove the various "member" sub-tabs, these are not helpful
- the "modules" tab is now called "topics" (since C++ has now Modules!)
- generally re-sync DoxygenLayout.xml with a current pristine template
- comb though the Doxygen Warnings and fix a lot of small problems
The »Outer Space« and »Inner Core« documents present a comprehensive
overview of the vision, architecture and essential parts of the implementation.
In the light of changes to policy, design and implementation approaches,
some updates were necessary to align these crucial texts with the current
state of planning and implementation. Notably I have added a recent Screenshot
of the UI, showing a nested track structure pushed up by Diff from the core.
Over the last weeks, I conducted an extended analysis of the inception time
of the Lumiera project, which gave me a sharpened understanding of the goals,
going forward. I have also written an in-depth essay "Complexity and Flexibility".
See the corresponding commits in the Website repository.
Expand on this problem with the consequences of rule changes.
Need to consider how recording this information is related
to the data structures of the Event-Log...
__Remark__: this topic belongs into the ''next planned'' Vertical Slice »LoadClip«
Allowing to change rules and facts seems to be in direct contradiction
to using an Event-Log for deterministic and reproducible behaviour.
Notably, the facts can be a representation of the environment,
like e.g. the sound setup in a Studio vs. working on a Laptop.
Since a long time, I used the formula to separate decisions
from the processing logic in the code. An analysis of the kinds
of decisions relevant for the situation with editing a media arrangement
reveals that a dangerous conflict might ensue when the foundation
of a past rule application changes, possibly by undo or replay
of the Event-Log.
A solution could be not only to apply rules, but also capture
and materialise the fact that a rule has been applied and
especially to record a connection between the setting and
the rule it was based on. This amounts to documenting
the reasoning why some decision came about. If done correct,
such a data model would allow to re-evaluate past decisions
quickly in case the facts or the rules are changed.
While I am currently deeply entrenched in the history of Lumiera
and related general questions of dealing with complexity, some
ramifications became clear for the next topics to address,
notably related to ''Event Sourcing''
The RfC documents were written to complement discussions of the Lumiera developers;
yet since the time where ''Ichthyo'' is working basically alone on the project,
this kind of discussions have ceased. During the following years, some ideas
promoted by the existing RfC documents became rather detached from the
actual state of development in the code base.
Many of the existing RfC documents require some commentary to place them
into context, and some of the decisions taken in the early stage of the
project should be **re-assessed**. This includes the decision to reject
some proposals, which initially might have seemed desirable, yet could not
be reconciled with the understanding of the matter and topic in question,
as was gained through the ongoing analysis and development.
Some sections of the Lumiera website document meeting minutes,
discussion protocols and design proposals from the early days
of the project; these pages were initially authored in the
»Moin Moin Wiki« operated by Cehteh on pipapo.org at that time;
this wiki backed the first publications of the »Cinelerra-3«
initiative, which turned into the Lumiera project eventually.
Some years later, those pages were transliterated into Asciidoc
semi-automatically, resulting in a lot of broken markup and links.
This is a long standing maintenance problem problem plaguing the
Lumiera website, since those breakages cause a lot of warnings
and flood the logs of any linkchecker run.
- indicate clearly that a ''past discussion'' is documented here
- point out what is the primary focus for UI design ''currently''
- arrange some links better
- use cross-links / Linkfarm; especially cross-link to
the discussion regarding Wouter's Workflow proposals (2025)
Create a new subcategory "design/architecture/time"
and rearrange several pages related to time handling and time codes.
NOTE: starting with this changeset, a ''Link-Farm'' is required for cross-links;
since we don't have an automatic solution for this task yet, I have created
the necessary forwarding pages manually in the website repository.
Christian started a series of reworks in 2018;
the result was considered experimental and was parked on website-staging ever since.
As part of the current release- and clean-up activities I now reviewed
and integrated those changes into the current website as far as applicable.
Topic: proposals for Lumiera Workflow
Present:
- Wouter Verweijlen
- Benny Lyons
- Hermann Voßeler
Note: This commit creates a new subsection
for the discussion related to Wouter's »Lumiera Workflow Proposals«....
The topic of this talk was ''Video output from a Linux desktop application''
after extended research we built a demo application in four flavours
(XVideo, SDL, OpenGL legacy / modern).
This research project was set off by our immediate needs for a setup
to show computed video pixel data in a viewer window in the GUI; the
investigated technologies should work at present and in the near term
future (yet leaving out Vulkan and Wayland)
Starting with the upcoming ''preview release'', branches, branch names and tags
will be rearranged to follow the Git-flow pattern instead of the existing
ad-hoc organisation with a release branch.
The documentation provided here defines the actual naming conventions
and some fine points regarding the version number upgrades
and placement of release tags.
Furthermore, two helper-scripts are provided to automate version number updates
- `buildVersion.py` : extract current version from git tag and allow to bump version
- `setVersion` : manipulate all relevant files with `sed` to update the version info
Yet another chainsaw massacre.
One of the most obnoxious annoyances with C++ metaprogramming
is the need to insert `typename` and `template` qualifiers into
most definitions, to help the compiler to cope with the syntax,
which is not context-free.
The recent standards adds several clarifications, so that most
of these qualifiers are redundant now, at least at places where
it is unambiguously clear that only a type can be given.
GCC already supports most of these relaxing rules
(Clang unfortunately lags way behind with support of newer language features...)
