ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

DOC: design index page improved and slightly extended

Browse source 
this is the entry point into the section holding the various
design documents -- we try to separatte conceptual/design
from the actual technical documentation
This commit is contained in:
Fischlurch 2013-01-04 01:45:47 +01:00
parent 7327b1ffb0
commit 21d2faff12
2 changed files with 57 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/design/architecture/playRender.txt
View file

@ -149,7 +149,7 @@ reconfigure the backend services.
Frame quantisation
^^^^^^^^^^^^^^^^^^
Quantisation is a kind of rounding; like any kind of rounding, quantisation is
link:../TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, quantisation is
a dangerous operation because it kills information content.
Thus there are three fundamental guidelines when it comes to rounding
@ -183,7 +183,7 @@ application the subsystem most remote and unaware of output requirements.
Which leaves us with the player and the session. Both positions could
arguably be supported. Here, a more careful consideration shows, that
the ``act of frame rounding'' can be decomposed: into the _act of quantisation_
and the _frame grid:. Basically its the session which has the ability
and the _frame grid_. Basically it's the session which has the ability
to form the *frame grid*, but it is lacking crucial information about
the output. Only when connecting both -- which is the essence of the
player -- frame quantisation can actually be performed. Thus, the

79
doc/design/index.txt
View file

@ -16,15 +16,21 @@ for the core of a Non-Linear Editing software. One of the key aspect of Lumiera
is the strong separation between the user interface and the processing core.
Lumiera as a software will come along with a GTK GUI but that does not make this
exclusive, any other GUI could be written as well as scripts to drive the core.
This is made possible by the above-mentioned quality of Lumiera being built against
clearly defined interfaces, strictly separating model and presentation. Lumiera
This is made possible by an ongoing effort to decrease coupling. Each major
component in the application strives to be open to extensions, but closed
against external modification. The presentation, the model and the ``performing''
of the model are separate and self-contained parts of the application. Lumiera
as a processing core will be able to do anything possibly conceivable, therefore it
may be used to do any task on video (and audio?), even unrelated to video editing.
.Workflow
****
The word Workflow is used to name the way tasks can be achieved in an application. Any operation in Lumiera must be possible in the most suitable and stringent fashion. The Workflow is closely related to how flexible the GUI is but also the concern of deeper and more technical parts of the application.
****
*****************
The word Workflow is used to name the way tasks can be achieved in an
application. Any operation in Lumiera must be possible in the most suitable and
stringent fashion. The Workflow is closely related to how flexible the GUI is
but also the concern of deeper and more technical parts of the application.
*****************
Overview
--------
@ -32,45 +38,70 @@ Overview
The internal structure of Lumiera is divided in numerous subsystems. This
overview will try to go through the elements from the highest to the lowest
piece of the structure. They can be categorized into three main categories plus
extra components :
extra components:
link:gui/index.html[Graphical User Interface]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
User interfaces are basically handled like plugins, consequently it is possible
Graphical User Interface
~~~~~~~~~~~~~~~~~~~~~~~~
User interfaces are basically included as a plugin, consequently it is possible
to interface with Lumiera through scripts. It is also possible to create
specialised GUIs. The interface is the closest component to the user, it is
purely visual. There the user manipulates, organizes, loads, configures all
sorts of data, especially MObjects (media objects) and Assets. These elements
are contained within a structure called the Session.
are contained within a structure called the Session. +
-> link:gui/index.html[GUI design documents]
The Processing Layer
~~~~~~~~~~~~~~~~~~~~
The Processing layer (or proc) is where the elements from the Session are
assembled to form a network of nodes, to be sent to the backend. The lowest data
structure is called the Low-level model. +
The processing layer (``Proc-layer'' or ``proc'') covers several closely related aspects.
While the user works with the GUI, all the clips, effects and other components presented
there are actually stored within the _Session model_ (``high-level model''). Any editing
operations initiated by the user are actually performed here. Next, after each change,
a component known as _the Builder_ assembles the contents of this model and transforms
them to form a network of nodes, which can be _performed_ efficiently for rendering.
Often, we refer to this node structure as the ``low-level model''. On rendering or
playback, the Proc-layer is responsible for accessing this node structure to
generate individual _frame render jobs,_ ready to be handed over to the backend
for the actual rendering calculations. +
-> more about the link:model/index.html[Model] +
-> design of the link:engine/index.html[Engine] subsystem
* link:model/index.html[Model] +
* link:engine/index.html[Engine]
link:backend/index.html[The Backend]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The backend uses the Low-level model. It allows the rendering and makes a heavy
use of the Input/Output System to the screen or to external monitors.
The Backend
~~~~~~~~~~~
The backend uses the Low-level model and the _render jobs_ generated by Proc.
It actually performs the the rendering operations and makes a heavy use of the
Input/Output System for accessing media content and sending generated data to
the screen or external output. +
-> link:backend/index.html[Backend design level documents] +
-> link:{ldoc}/technical/backend/index.html[technical documentation] +
Extra components
----------------
link:application/index.html[The Application]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Application
~~~~~~~~~~~~~~~
The application controls the initialization and shutdown procedures as well as
loading external elements like plugins that are widely used.
loading external elements like plugins that are widely used. It acts as a framework
to support the operation of the core components. This framework is complemented by
a library of commonly used components, algorithms and data structures. +
-> link:application/index.html[Application framework]
link:plugins/index.html[Plugins]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Plugins are key elements in Lumiera since the application relies heavily on this
concept of modules. For example, the GUI of Lumiera is a plugin.
Plugins play an important role within Lumiera since the application relies heavily
existing implementations and external libraries. Moreover, the application is envisioned
to be configurable and can be extended in various ways; whenever some extension isn't permanent
or will be used only on demand, it is packaged as separate module into a plug-in. For example,
the GUI of Lumiera is a plugin. +
-> design doruments regarding the link:plugins/index.html[Plugins]