diff --git a/doc/devel/uml/class130949.html b/doc/devel/uml/class130949.html index 774585ac5..05f451c34 100644 --- a/doc/devel/uml/class130949.html +++ b/doc/devel/uml/class130949.html @@ -18,7 +18,7 @@

Declaration :

Encapsulates the logic used to get a "current render process" in accordance to the currentyl applicable controller settings. The provided StateProxy serves to hold any mutalbe state used in the render process, so the rest of the render engine can be stateless.

Artifact : renderstate

-
Operation getStateProxy

Declaration :

+
Operation getStateProxy

Declaration :

All public operations : getStateProxy

diff --git a/doc/devel/uml/class131589.html b/doc/devel/uml/class131589.html index c65bef7fb..beefcf13d 100644 --- a/doc/devel/uml/class131589.html +++ b/doc/devel/uml/class131589.html @@ -18,5 +18,6 @@

Declaration :

The output of the render pipeline. Pulling from such exit nodes actually ivokes the render process

Artifact : exitnode

+

All public operations : pull

diff --git a/doc/devel/uml/class131717.html b/doc/devel/uml/class131717.html index d03898369..8952f6f05 100644 --- a/doc/devel/uml/class131717.html +++ b/doc/devel/uml/class131717.html @@ -20,6 +20,9 @@

Key abstraction of the Render Engine: A Data processing Node

Artifact : procnode

Relation datasrc (<unidirectional association>)

Declaration :

The predecessor in a processing pipeline, i.e. a source to get data to be processed

-
Relation params (<directional aggregation by value>)

Declaration :

+
Relation params (<directional aggregation by value>)

Declaration :

+
Operation pull

Declaration :

trigger data processing by "pulling" results from the node's output

+
Relation predecessors (<directional aggregation by value>)

Declaration :

preconfigured table of all predecessor nodes, qualified
with the output port on these nodes and time offset of the data
we need for doing our calculations

+

All public operations : pull

diff --git a/doc/devel/uml/class131845.html b/doc/devel/uml/class131845.html index 278d1cdb1..c59787b25 100644 --- a/doc/devel/uml/class131845.html +++ b/doc/devel/uml/class131845.html @@ -19,5 +19,6 @@

Declaration :

Directly inherited by : CodecAdapter Mask PluginAdapter Projector

Artifact : trafo

+

All public operations : pull

diff --git a/doc/devel/uml/class131973.html b/doc/devel/uml/class131973.html index 68e7e24de..82d637b48 100644 --- a/doc/devel/uml/class131973.html +++ b/doc/devel/uml/class131973.html @@ -19,5 +19,6 @@

Declaration :

Directly inherited by : GLPipe

Artifact : link

+

All public operations : pull

diff --git a/doc/devel/uml/class132101.html b/doc/devel/uml/class132101.html index ca7d5ac7e..50eae3f1b 100644 --- a/doc/devel/uml/class132101.html +++ b/doc/devel/uml/class132101.html @@ -18,5 +18,6 @@

Declaration :

Artifact : hub

+

All public operations : pull

diff --git a/doc/devel/uml/class132229.html b/doc/devel/uml/class132229.html index f0ba8e9d7..28f198354 100644 --- a/doc/devel/uml/class132229.html +++ b/doc/devel/uml/class132229.html @@ -18,5 +18,6 @@

Declaration :

Special video processing node used to scale and translate image data.

Artifact : projector

+

All public operations : pull

diff --git a/doc/devel/uml/class132357.html b/doc/devel/uml/class132357.html index 0d94f52bc..9dab6ff1f 100644 --- a/doc/devel/uml/class132357.html +++ b/doc/devel/uml/class132357.html @@ -18,5 +18,6 @@

Declaration :

Artifact : mask

+

All public operations : pull

diff --git a/doc/devel/uml/class132485.html b/doc/devel/uml/class132485.html index b6389bd12..2ccb92506 100644 --- a/doc/devel/uml/class132485.html +++ b/doc/devel/uml/class132485.html @@ -18,5 +18,6 @@

Declaration :

Adapter used to integrage an effects processor in the render pipeline

Artifact : pluginadapter

+

All public operations : pull

diff --git a/doc/devel/uml/class132613.html b/doc/devel/uml/class132613.html index 0134205d1..763de044c 100644 --- a/doc/devel/uml/class132613.html +++ b/doc/devel/uml/class132613.html @@ -18,5 +18,6 @@

Declaration :

specialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form

Artifact : glpipe

+

All public operations : pull

diff --git a/doc/devel/uml/class132741.html b/doc/devel/uml/class132741.html index f0a749926..f543def13 100644 --- a/doc/devel/uml/class132741.html +++ b/doc/devel/uml/class132741.html @@ -4,21 +4,21 @@ -Class StateProxy +Class State -
Class StateProxy
+
Class State

-

Declaration :

Directly inherited by : ARender GLRender VRender

+

Declaration :

Directly inherited by : ARender GLRender StateAdapter StateProxy VRender

Artifact : stateproxy, Component(s) : Builder

-
Relation currFrame (<unidirectional association>)

Declaration :

+
Relation currFrame (<unidirectional association>)

Declaration :

diff --git a/doc/devel/uml/class132869.html b/doc/devel/uml/class132869.html index 743378103..2d6833c2a 100644 --- a/doc/devel/uml/class132869.html +++ b/doc/devel/uml/class132869.html @@ -16,7 +16,7 @@ -

Declaration :

Representation of a Audio render process

Artifact : arender

+

Declaration :

Representation of a Audio render process

Artifact : arender

diff --git a/doc/devel/uml/class132997.html b/doc/devel/uml/class132997.html index 7680639be..a45d3c828 100644 --- a/doc/devel/uml/class132997.html +++ b/doc/devel/uml/class132997.html @@ -16,7 +16,7 @@ -

Declaration :

Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)

Artifact : vrender

+

Declaration :

Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)

Artifact : vrender

diff --git a/doc/devel/uml/class133125.html b/doc/devel/uml/class133125.html index 140cc4b67..d1cf4b2b6 100644 --- a/doc/devel/uml/class133125.html +++ b/doc/devel/uml/class133125.html @@ -16,7 +16,7 @@ -

Declaration :

Representation of a OpenGL accelerated Video render process

Artifact : glrender

+

Declaration :

  • C++ : class GLRender : public State

Representation of a OpenGL accelerated Video render process

Artifact : glrender

diff --git a/doc/devel/uml/class133765.html b/doc/devel/uml/class133765.html index af0e6bfb1..384101f0a 100644 --- a/doc/devel/uml/class133765.html +++ b/doc/devel/uml/class133765.html @@ -18,5 +18,6 @@

Declaration :

Source Node: represents a media source to pull data from.

Artifact : source

+

All public operations : pull

diff --git a/doc/devel/uml/class135045.html b/doc/devel/uml/class135045.html index 16259137b..a651d86b1 100644 --- a/doc/devel/uml/class135045.html +++ b/doc/devel/uml/class135045.html @@ -18,5 +18,6 @@

Declaration :

  • C++ : class CodecAdapter : public Trafo

Artifact : codecadapter

+

All public operations : pull

diff --git a/doc/devel/uml/class142085.html b/doc/devel/uml/class142085.html new file mode 100644 index 000000000..70fbc4c7b --- /dev/null +++ b/doc/devel/uml/class142085.html @@ -0,0 +1,22 @@ + + + + + + +Class StateProxy + + + + + +
Class StateProxy
+

+ + + + +

Declaration :

  • C++ : class StateProxy : public State
+
+ + diff --git a/doc/devel/uml/class142213.html b/doc/devel/uml/class142213.html new file mode 100644 index 000000000..a43acb9ac --- /dev/null +++ b/doc/devel/uml/class142213.html @@ -0,0 +1,27 @@ + + + + + + +Class StateAdapter + + + + + +
Class StateAdapter
+

+ + + + +

Declaration :

  • C++ : class StateAdapter : public State

lightweight value class used to manage the buffer associations for a single pull() call on a processing node

+ +
Operation pull

Declaration :

  • Uml : + pull(inout renderProcess : State) : void
  • C++ : public: void pull ()

trigger data processing by "pulling" results from the node's output

+
Operation retrieveBuffers

Declaration :

  • Uml : + retrieveBuffers(in requiredSource : vector<InputDescriptor> const) : void
  • C++ : public: void retrieveBuffers (const vector<InputDescriptor> const& requiredSource)

invoked from within the pull() - call of a node to set up the data buffers.
@param requiredSource descriptor denoting the predecessors and the frames required from them

+
Relation <unidirectional association>

Declaration :

+
Relation state (<unidirectional association>)

Declaration :

+

All public operations : pull , retrieveBuffers

+ + diff --git a/doc/devel/uml/class142341.html b/doc/devel/uml/class142341.html new file mode 100644 index 000000000..e9ac0ff67 --- /dev/null +++ b/doc/devel/uml/class142341.html @@ -0,0 +1,20 @@ + + + + + + +Class InputDescriptor + + + + + +
Class InputDescriptor
+

+ + + + +

Declaration :

  • C++ : class InputDescriptor

Artifact : procnode

+ diff --git a/doc/devel/uml/class142469.html b/doc/devel/uml/class142469.html new file mode 100644 index 000000000..9b6ed01a1 --- /dev/null +++ b/doc/devel/uml/class142469.html @@ -0,0 +1,20 @@ + + + + + + +Class caller + + + + + +
Class caller
+

+ + + + +

Declaration :

  • C++ : class caller
+ diff --git a/doc/devel/uml/class142597.html b/doc/devel/uml/class142597.html new file mode 100644 index 000000000..6465a8cd5 --- /dev/null +++ b/doc/devel/uml/class142597.html @@ -0,0 +1,20 @@ + + + + + + +Class Backend_Cache + + + + + +
Class Backend_Cache
+

+ + + + +

Declaration :

  • C++ : class Backend_Cache
+ diff --git a/doc/devel/uml/classdiagrams.html b/doc/devel/uml/classdiagrams.html index 4cf5416cc..c08c6d8a8 100644 --- a/doc/devel/uml/classdiagrams.html +++ b/doc/devel/uml/classdiagrams.html @@ -20,6 +20,7 @@ Automation Entities Builder Entities Controller Entities +Engine Details File MappingShows whats used to access Frames HierarchyLumiera Exception hierarchy In Memory Database diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 23162b8f6..e1343f56e 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -26,10 +26,12 @@ AssetinterfaceSuperinterface describing especially the bookeeping properties of Assets AssetManagerboundaryFacade for the Asset subsystem AutoAutomation data for some parameter (i.e. a time varying function) +Backend_Cache Buildableinterface BuilderFacadeboundaryProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade BuilderToolinterfaceUsed according to the visitor pattern: each Tool contains the concrete implementation for one task to be done to the various MObject classes BuildInstruct(Interface) building instructions to be executed by the Builder on the render node network under construction. +caller Categorytree like classification of Assets Clipbookkeeping (asset) view of a media clip. Clip @@ -74,6 +76,7 @@ GLPipespecialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form GLRenderRepresentation of a OpenGL accelerated Video render process Hub +InputDescriptor InterpolatorProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter Invalid Label @@ -101,6 +104,7 @@ Prefetch Previewalternative version of the media data, probably with lower resolution Prockey abstraction: data processing asset +ProcDispatcher Processor ProcNodeinterfaceKey abstraction of the Render Engine: A Data processing Node ProcPattspecial type of structural Asset representing information how to build some part of the render engine's processing nodes network. @@ -122,8 +126,10 @@ SimpleClipElementary clip consisting of only one media stream SmartPointerauxiliary SourceSource Node: represents a media source to pull data from. +Stateinterface State -StateProxyinterface +StateAdapterlightweight value class used to manage the buffer associations for a single pull() call on a processing node +StateProxyimplementation std::exceptionauxiliary Structkey abstraction: structural asset ThreadWe can basically reuse the Thread class design from Cinelerra2, Thread becomes a baseclass for all Threads diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 6f3005da9..153e47670 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -27,10 +27,12 @@ Asset
AssetManager
Auto
+Backend_Cache
Buildable
BuilderFacade
BuilderTool
BuildInstruct
+caller
Category
Clip
Clip
@@ -75,6 +77,7 @@ GLPipe
GLRender
Hub
+InputDescriptor
Interpolator
Invalid
Label
@@ -102,6 +105,7 @@ Prefetch
Preview
Proc
+ProcDispatcher
Processor
ProcNode
ProcPatt
@@ -123,8 +127,10 @@ SimpleClip
SmartPointer
Source
+State
State
-StateProxy
+StateAdapter
+StateProxy
std::exception
Struct
Thread
diff --git a/doc/devel/uml/collaborationdiagrams.html b/doc/devel/uml/collaborationdiagrams.html index 2d8ab627d..9090762bc 100644 --- a/doc/devel/uml/collaborationdiagrams.html +++ b/doc/devel/uml/collaborationdiagrams.html @@ -18,6 +18,7 @@ +
"default" object
build processThis figure shows the process of building and starting a RenderEngine
pull call
diff --git a/doc/devel/uml/fig128389.png b/doc/devel/uml/fig128389.png index c6a57b857..adc3952e4 100644 Binary files a/doc/devel/uml/fig128389.png and b/doc/devel/uml/fig128389.png differ diff --git a/doc/devel/uml/fig131973.png b/doc/devel/uml/fig131973.png new file mode 100644 index 000000000..31b9b2a18 Binary files /dev/null and b/doc/devel/uml/fig131973.png differ diff --git a/doc/devel/uml/fig132101.png b/doc/devel/uml/fig132101.png new file mode 100644 index 000000000..de8af3d00 Binary files /dev/null and b/doc/devel/uml/fig132101.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index bbecbcbc0..a054cc161 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -32,7 +32,7 @@ Documentation

provided classes : Error, Time

Component Builder
-

provided classes : StateProxy

+

provided classes : State

required classes : Fixture, SessionImpl

Component Session
@@ -54,9 +54,10 @@ Documentation
Component AssetManagement
Component Dispatcher
+

provided classes : ProcDispatcher

Component Engine
-

Depends on Frame (Stream) Provider

required classes : StateProxy

+

Depends on Frame (Stream) Provider

required classes : State

Component ProcNode
@@ -78,6 +79,9 @@ Documentation

required classes : MediaAccessFacade

Component AssetDB
+ +
Component client code
+

required classes : ProcDispatcher

1.2 Component View interfaces

@@ -112,7 +116,7 @@ Documentation
Artifact Lumiera

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool

+

executable associated with : placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame

Artifact main

Artifact source

@@ -192,7 +196,7 @@ Documentation
Artifact stateproxy

Key Interface representing a render process and encapsulating state

-

Artifact source associated with : StateProxy

+

Artifact source associated with : State

Artifact controllerfacade

Facade and service access point for the Proc Layer Controller

@@ -505,7 +509,7 @@ Documentation
Artifact procnode

Key abstraction of the Render Engine: a Processing Node

-

Artifact source associated with : ProcNode

+

Artifact source associated with : ProcNode, InputDescriptor

Artifact trafo

transforming processing Node

@@ -670,6 +674,7 @@ Documentation
Class ParamProvider
Class Interpolator
Class LocatingPin
+
Class ProcDispatcher

2.2.2 Package Builder

@@ -759,7 +764,6 @@ Documentation
Class ToolFactory
Class ConManager
Class Assembler
-
Class StateProxy
Class Buildable
Class BuilderTool
Class SegmentationTool
@@ -892,6 +896,27 @@ reuse exiting Engine

Selection :

Transformation
Class VFrame
Class GLBuf
Class Source
+ +

+

Engine Details



+
Class State
+
Class StateProxy
+
Class StateAdapter
+
Class InputDescriptor
+
+ +

2.3.3 Use Case View render process

+
+ +

+

pull call



+ +
Class instance

type :StateAdapter

+
Class instance node1

type :ProcNode

+
Class instance node2

type :ProcNode

+
Class instance next_adapter

type :StateAdapter

+
Class instance current_state

type :StateProxy

Class caller
+
Class Backend_Cache
diff --git a/doc/devel/uml/index_60.html b/doc/devel/uml/index_60.html index 4909e634c..8712d7074 100644 --- a/doc/devel/uml/index_60.html +++ b/doc/devel/uml/index_60.html @@ -17,8 +17,8 @@ - + @@ -28,8 +28,8 @@ - + diff --git a/doc/devel/uml/index_65.html b/doc/devel/uml/index_65.html index 3fce72879..c1c05066a 100644 --- a/doc/devel/uml/index_65.html +++ b/doc/devel/uml/index_65.html @@ -55,9 +55,9 @@ - - + + diff --git a/doc/devel/uml/index_66.html b/doc/devel/uml/index_66.html index 2d9540c91..592c6f15d 100644 --- a/doc/devel/uml/index_66.html +++ b/doc/devel/uml/index_66.html @@ -21,6 +21,7 @@ + @@ -34,8 +35,8 @@ - + diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index 08c04b765..996ed7eb6 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -19,6 +19,7 @@ + @@ -27,38 +28,40 @@ - - - - - - + + + + + + - - - - - - - + - - - - - + + - + + + + + + + + + + + + - + @@ -105,6 +108,7 @@ +
NameKindDescription
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
<flow>transition
aud_Aclass instance
aud_aclass instance
audioclass instance
audio1class instance
audio1class instance
audio1class instance
audio1class instance
audio1class instance
autoartifactMedia Object holding automation data
AutoclassAutomation data for some parameter (i.e. a time varying function)
Automation Entitiesclass diagram
Backend Componentsclass view
backend use casesuse case diagram
backend-componentscomponent diagram
Backend_Cacheclass
BackendLayerpackage
buildoperation
build flowactivity diagram
buildableartifactmarker interface denoting any MObject able to be treated by Tools
buildEngineoperationMain Operation of the Builder: create a render engine for a given part of the timeline
Buildercomponent
Builderpackage
builderpackagesourcecode package

The Builder creating the Render Engine,
located within the MObject Subsystem
Builderpackage
Builder Entitiesclass diagram
Builder Workingsclass view
BuilderFacadeclassProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade
NameKindDescription
Cachecomponent
Cachecomponent view
callerclass
categoryrelationprimary tree like classification of the asset
Categoryclasstree like classification of Assets
categoryartifacttree like classification of Assets
chainoperationcreate and add another Placement for this media object, thus increasingly constraining the (possible) position of this object.
checked_inrelationchecked_in objects are subject of cache aging and must be not in use
checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
class instanceclass instance
clearoperationclear current session contents
without resetting overall session config.
Afterwards, the session will contain only one
empty EDL, while all Assets are retained.
client codecomponent
Clipclassbookkeeping (asset) view of a media clip.
clipartifactbookkeeping (asset) view of a media clip.
clipartifacta Media Clip
clipartifactbookkeeping (asset) view of a media clip.
Clipclass
clipsrelation
Codecclassdescription of some media data decoder or encoder facility
createClipoperationcreate a (possibly compound) Clip refering to this media, ready to be added to the EDL.
currEDLoperationThe EDL currently in focus. In most cases, Session and EDL are almost the same, just EDL emphasizes the collection aspect. But generally (for larger editing projects) one Session can contain several EDLs, which may even be nested. At any given time, only one of these EDLs has focus and recieves the editing commands.
currentrelationStandard access path to get at the current session via the Session Manager, which acts as a "PImpl" smart pointer
current_stateclass instance
currFramerelation
diff --git a/doc/devel/uml/index_68.html b/doc/devel/uml/index_68.html index 90bc7ba4d..e9e768a1e 100644 --- a/doc/devel/uml/index_68.html +++ b/doc/devel/uml/index_68.html @@ -32,8 +32,8 @@ designpackage designpackageAll things concering the big picture.
Not a real code package, rather a container for design drafts, specifications, decisions. detect Channelsuse case -determine Render Paramsexpansion region determine Render Paramsopaque activity action +determine Render Paramsexpansion region devnullclass instance Dispatchercomponent dispatchOpoperation diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index 6c17d406d..c9eb2c76d 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -18,20 +18,21 @@ - + - + + diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index 78b986b1b..f328ad207 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -34,8 +34,8 @@ - + diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 798945020..fa68d81e1 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -20,9 +20,10 @@ - + + diff --git a/doc/devel/uml/index_77.html b/doc/devel/uml/index_77.html index e6d8e8031..1428ef6eb 100644 --- a/doc/devel/uml/index_77.html +++ b/doc/devel/uml/index_77.html @@ -33,8 +33,8 @@ - + diff --git a/doc/devel/uml/index_78.html b/doc/devel/uml/index_78.html index 1cf51971d..8afac3d9f 100644 --- a/doc/devel/uml/index_78.html +++ b/doc/devel/uml/index_78.html @@ -20,6 +20,9 @@ + + + diff --git a/doc/devel/uml/index_79.html b/doc/devel/uml/index_79.html index 4ac4c3b33..f63687c5b 100644 --- a/doc/devel/uml/index_79.html +++ b/doc/devel/uml/index_79.html @@ -19,9 +19,9 @@ - - + + diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index ba34ae763..83ab6f76d 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -40,6 +40,7 @@ + @@ -51,6 +52,7 @@ + @@ -62,6 +64,9 @@ + + +
NameKindDescription
edlartifactthe (high level) Edit Decision List within the current Session
EDLclass
EDLcomponent
EDLclass
EDL Example1object diagramA simple example showing how the actual objects are placed in the Fixture (=definitive playlist). It shows a Video and Audio clip placed on two tracks
EDL Example2object diagramMore complex example showing the Object graph in the EDL and how it is linked into the Fixture to yield the actual locations. In this example, an HUE Effect is applied on a part of the Clip
edlsrelation
EffectclassEffect or media processing component
effectartifactEDL representation of a pluggable and automatable effect.
effectartifactEffect or media processing component
effectartifactEDL representation of a pluggable and automatable effect.
Effectclass
elementsrelationrelevant MObjects comprising this segment. TODO: actually necessary??
enableoperationchange the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well
endattributeend of the timerange (excl)
Enginecomponent
enginepackagesourcecode package

The Core Render Engine
Engine Detailsclass diagram
Engine Example1object diagramExample1 (from EDL) continued: here the RenderEngine to be created by the Builder from the Input shown in Example1
Engine Example2object diagramExample2 (from EDL) continued: notably in this RenderEngine the Effect has been partitioned into 2 segments with constant configuration.
Engine Partsdeployment view
FixedLocationclass
Fixtureactivity object
fixtureartifactthe (low level) representation of the EDL with concrete placement data
Fixturecomponent
Fixtureclass
Fixturecomponent
fork activity nodefork activity node
FrameclassFrames are just a low level lump of continous memory, most parts are opaque. Frames are memory sensitive, they will be small constant sized structures which can be efficently managed in a pool.
Framenode
idattributeAsset primary key.
In Memory Databaseclass diagram
inFixtureactivity action pin
inputclass instance
inputclass instance
inputclass instance
inputclass instance
InputDescriptorclass
instanceoperation
instructionsrelation
Interfaceclass view
MediaFactoryclassspecialized Asset Factory for configuring (new) media asset instances based on existing media files on disk; can create placeholder assets as well
merge activity nodemerge activity node
Metaclasskey abstraction: metadata and organisational asset
metaartifactkey abstraction: metadata and organisational asset
metaartifactabstract base class of all MObjects representing meta data or processing instructions
metaartifactkey abstraction: metadata and organisational asset
Metaclass
mobjectartifactKey Abstraction: A Media Object in the Session
mobjectpackagesourcecode package

MObject Subsystem
including the Session (EDL), Builder and Processing Controller
nameattributeelement ID, comprehensible but sanitized. The tuple (category, name, org) is unique.
need sub objectuse case
nextrelationnext additional LocatingPin, if any
next_adapterclass instance
node1class instance
node2class instance
nodecreatertoolartifactcentral Tool implementing the Renderengine building
NodeCreatorToolclassThis Tool implementation plays the central role in the buld process: given a MObject from Session, it is able to attach ProcNodes to the render engine under construction such as to reflect the properties of the MObject in the actual render.
nodesrelation
NameKindDescription
offsetattributeOffset the actual position by this (time) value relative to the anchor point. TODO: Representation?
orgattributeorigin or authorship id. Can be a project abbreviation, a package id or just the authors nickname or UID. This allows for the compnent name to be more generic (e.g. "blur"). Default for all assets provided by the core Lumiera codebase is "lumi".
ouputclass instance
ouputclass instance
ouputclass instance
ouputclass instance
ouputclass instance
outPortrelationthe Port this MObject wants to be conected to
outputrelation
Overviewcomponent diagramThis drawing shows the top level compoents and relations
pnodenode
pointattributeidentifying the point where the nodes should be attached
Posix Threads Abstractionclass viewC++ wrapers for pthreads
predecessorsrelationpreconfigured table of all predecessor nodes, qualified
with the output port on these nodes and time offset of the data
we need for doing our calculations
predicate implclass instance
Prefetchclass
Previewclassalternative version of the media data, probably with lower resolution
procattributeholds the Processor (Render Engine Element) to be built by the current build step
Proc-Asset Relationsclass diagram
proc-componentscomponent diagram
ProcDispatcherclass
ProcessingLayerpackage
Processorclass
processorartifacta single render pipeline for one segment of the timeline
ProjectorclassSpecial video processing node used to scale and translate image data.
projectorartifactvideo ProcNode for scaling and translating image data
providerrelation
pulloperationtrigger data processing by "pulling" results from the node's output
pulloperationtrigger data processing by "pulling" results from the node's output
pull callcollaboration diagram
diff --git a/doc/devel/uml/index_82.html b/doc/devel/uml/index_82.html index 1bade53e8..c807e8ca4 100644 --- a/doc/devel/uml/index_82.html +++ b/doc/devel/uml/index_82.html @@ -22,10 +22,11 @@ registryrelation@internal Table or DB holding all registered asset instances. relativelocationartifactPlacement implemnetaion providing various ways of attaching a MObject to another one RelativeLocationclass -RelTypeclassthe possible kinds of RelativePlacements relTypeattributethe kind of relation denoted by this Placement +RelTypeclassthe possible kinds of RelativePlacements removeoperationremove the given asset <i>together with all its dependants</i> from the internal DB Render Entitiesclass diagram +render processuse case view Render Requestactivity parameter RenderEngineclass renderengineartifacta complete network of processing nodes usable for rendering @@ -42,6 +43,7 @@ resolveoperation Resolvercomponent ResolverBaseclass +retrieveBuffersoperationinvoked from within the pull() - call of a node to set up the data buffers.
@param requiredSource descriptor denoting the predecessors and the frames required from them rootCauseoperationIf this exception was caused by a chain of further exceptions,
return the first one registered in this throw sequence.
This works only, if every exceptions thrown as a consequence
of another exception is propperly constructed by passing
the original exception to the constructor Rule Basecomponent Rules accessclass diagram diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index e2f2fcea3..2edde4200 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -32,8 +32,8 @@ Service Componentsclass view Sessioncomponent sessionartifactInterface: the session edited by the user -Sessionclass view sessionpackagesourcecode package

Everything concerning the EDL and Session, within the MObject Subsystem +Sessionclass view SessionclassPrimary Interface for all editing tasks.
The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered. Session structureclass diagram sessionimplartifactholds the complete session data to be edited by the user @@ -56,8 +56,11 @@ startattributebegin of the timerange covered by this processor startattribute Statenode +Stateclass Stateclass -StateProxyclass +staterelation +StateAdapterclasslightweight value class used to manage the buffer associations for a single pull() call on a processing node +StateProxyclass stateproxyartifactKey Interface representing a render process and encapsulating state std::exceptionclass Structclasskey abstraction: structural asset diff --git a/doc/devel/uml/index_84.html b/doc/devel/uml/index_84.html index 14d928057..bfcae496d 100644 --- a/doc/devel/uml/index_84.html +++ b/doc/devel/uml/index_84.html @@ -34,20 +34,20 @@ trackrelation trackattribute trackrelation -trackartifactA grouping device within the EDL. The corresponding Placement
by which this Track object is refered defines fallback placing
properties to be used by all objects placed on this track in
case they don't specify more concrete placements.
Typically, tracks are used do make default Port connections,
define a layer or pan for sound and for for disabling groups
of clips. Note tracks are grouped in a tree like fashion.
trackartifactstructural asset holding the configuration of a track in the EDL +trackartifactA grouping device within the EDL. The corresponding Placement
by which this Track object is refered defines fallback placing
properties to be used by all objects placed on this track in
case they don't specify more concrete placements.
Typically, tracks are used do make default Port connections,
define a layer or pan for sound and for for disabling groups
of clips. Note tracks are grouped in a tree like fashion.
Trackclass tracksrelationelementary media assets comprising this compound Trafoclass trafoartifacttransforming processing Node treatoperation treatoperationThis operation is to be overloaded for the specific MObject subclasses to be treated. -treatoperation treatoperation treatoperation treatoperation -treatoperation +treatoperation treatoperation +treatoperation treatoperation TypeHandlerclass TypeHandler<Pipe>class diff --git a/doc/devel/uml/index_86.html b/doc/devel/uml/index_86.html index e3c5f01a9..364ff0811 100644 --- a/doc/devel/uml/index_86.html +++ b/doc/devel/uml/index_86.html @@ -20,23 +20,23 @@ versionattributeversion number of the thing or concept represented by this asset. Of each unique tuple (name, category, org) there will be only one version in the whole system. Version 0 is reserved for internal purposes. Versions are considered to be ordered, and any higher version is supposed to be fully backwards compatible to all previous versions. VFrameclass vframeartifacta buffer and render process holding a Video frame -vid1class instance vid1class instance -vid_Aclass instance -vid_Aclass instance +vid1class instance vid_aclass instance -vid_aclass instance +vid_Aclass instance vid_Aclass instance -videoclass instance +vid_aclass instance +vid_Aclass instance videoclass instance -videoclass instance videoclass instance -video1class instance -video1class instance -video1class instance -video1class instance +videoclass instance +videoclass instance video1class instance +video1class instance +video1class instance video1class instance +video1class instance +video1class instance Visitableclass visitorpackagesub-namespace for visitor library implementation visitorartifactAcyclic Visitor library diff --git a/doc/devel/uml/public_operations.html b/doc/devel/uml/public_operations.html index 697d67b52..03a780210 100644 --- a/doc/devel/uml/public_operations.html +++ b/doc/devel/uml/public_operations.html @@ -51,11 +51,14 @@ loadSessManagerreplace the current session by a new
session loaded from serialized state. makeTypeHandler playRenderEngineTODO: will probably be handled differently (see Cehteh) +pullProcNodetrigger data processing by "pulling" results from the node's output +pullStateAdaptertrigger data processing by "pulling" results from the node's output removeAssetManagerremove the given asset <i>together with all its dependants</i> from the internal DB resetSessManagerreset all session config and
start with a pristine default session. resolvePlacementcreate an actual (explicit) placement while trying to satisfy the network of adjacent objects and placements. resolveQueryHandler resolveQueryHandlerImpl +retrieveBuffersStateAdapterinvoked from within the pull() - call of a node to set up the data buffers.
@param requiredSource descriptor denoting the predecessors and the frames required from them rootCauseErrorIf this exception was caused by a chain of further exceptions,
return the first one registered in this throw sequence.
This works only, if every exceptions thrown as a consequence
of another exception is propperly constructed by passing
the original exception to the constructor saveSessManagercreate a complete, serialized representation
of the current session config and contents.
@todo how to serialize, prameters, return value? treatApplicable diff --git a/uml/lumiera/128389.diagram b/uml/lumiera/128389.diagram index 5a6ad5049..741cf9ff5 100644 --- a/uml/lumiera/128389.diagram +++ b/uml/lumiera/128389.diagram @@ -14,7 +14,7 @@ classcanvas 128389 class_ref 131589 // ExitNode end classcanvas 128517 class_ref 131717 // ProcNode draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 462 264 2000 + xyz 462 257 2000 end classcanvas 129029 class_ref 131845 // Trafo draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default @@ -44,7 +44,7 @@ classcanvas 129797 class_ref 132613 // GLPipe draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 699 531 2000 end -classcanvas 132229 class_ref 132741 // StateProxy +classcanvas 132229 class_ref 132741 // State draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 36 374 2000 end @@ -97,29 +97,29 @@ relationcanvas 128901 relation_ref 131973 // multiplicity_a_pos 414 419 3000 no_multiplicity_b relationcanvas 129925 relation_ref 132101 // geometry VHV - from ref 128389 z 1999 to point 445 384 - line 130693 z 1999 to point 499 384 + from ref 128389 z 1999 to point 445 387 + line 130693 z 1999 to point 499 387 line 130821 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 130053 relation_ref 132229 // geometry VHV - from ref 129029 z 1999 to point 516 383 - line 130949 z 1999 to point 499 383 + from ref 129029 z 1999 to point 516 387 + line 130949 z 1999 to point 499 387 line 131077 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 130181 relation_ref 132357 // geometry VHV - from ref 129285 z 1999 to point 613 384 - line 131205 z 1999 to point 499 384 + from ref 129285 z 1999 to point 613 387 + line 131205 z 1999 to point 499 387 line 131333 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 130309 relation_ref 132485 // geometry VHV - from ref 129157 z 1999 to point 668 384 - line 131461 z 1999 to point 499 384 + from ref 129157 z 1999 to point 668 387 + line 131461 z 1999 to point 499 387 line 131589 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b @@ -179,14 +179,14 @@ relationcanvas 135429 relation_ref 134149 // no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 136965 relation_ref 134533 // - from ref 132229 z 1999 to point 306 465 + from ref 132229 z 1999 stereotype "<>" xyz 279 441 3000 to point 306 465 line 137093 z 1999 to ref 133765 role_a_pos 318 587 3000 no_role_b - no_multiplicity_a multiplicity_b_pos 124 427 3000 + multiplicity_a_pos 282 587 3000 multiplicity_b_pos 124 427 3000 relationcanvas 137349 relation_ref 134661 // geometry VHV - from ref 137221 z 1999 to point 763 384 - line 137477 z 1999 to point 499 384 + from ref 137221 z 1999 to point 763 387 + line 137477 z 1999 to point 499 387 line 137605 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b diff --git a/uml/lumiera/129285 b/uml/lumiera/129285 index 28f619bb6..7883c598c 100644 --- a/uml/lumiera/129285 +++ b/uml/lumiera/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 14 + revision 15 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/lumiera/131973.diagram b/uml/lumiera/131973.diagram new file mode 100644 index 000000000..9d11f2c5a --- /dev/null +++ b/uml/lumiera/131973.diagram @@ -0,0 +1,67 @@ +format 40 + +classcanvas 128005 class_ref 131717 // ProcNode + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 106 330 2004 + end +classcanvas 128517 class_ref 132741 // State + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 83 21 2000 + end +classcanvas 128645 class_ref 142085 // StateProxy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 127 135 2000 + end +classcanvas 128773 class_ref 142213 // StateAdapter + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 36 216 2000 + end +classcanvas 129157 class_ref 142341 // InputDescriptor + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 183 446 2000 + end +classcanvas 129669 class_ref 133253 // Frame + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 267 221 3005 + end +relationcanvas 128901 relation_ref 148229 // + geometry VHV unfixed + from ref 128645 z 1999 to point 179 108 + line 131589 z 1999 to point 120 108 + line 131717 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129029 relation_ref 148357 // + geometry VHV unfixed + from ref 128773 z 1999 to point 80 108 + line 131333 z 1999 to point 120 108 + line 131461 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129285 relation_ref 148485 // + geometry HV + from ref 128005 z 1999 to point 228 367 + line 129541 z 1999 to ref 129157 + role_a_pos 240 421 3000 no_role_b + multiplicity_a_pos 216 421 3000 no_multiplicity_b +relationcanvas 129797 relation_ref 134533 // + from ref 128517 z 1999 to point 303 129 + line 130053 z 1999 stereotype "<>" xyz 248 128 3000 to ref 129669 + role_a_pos 312 194 3000 no_role_b + multiplicity_a_pos 281 158 3000 multiplicity_b_pos 171 82 3000 +relationcanvas 129925 relation_ref 148613 // + from ref 128773 z 1999 to ref 129669 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 130181 relation_ref 148741 // + from ref 128773 z 1999 to point 179 226 + line 130309 z 1999 to ref 128645 + role_a_pos 149 210 3000 no_role_b + no_multiplicity_a no_multiplicity_b +line 130437 -_-_ + from ref 128773 z 1999 to point 136 328 + line 130693 z 1999 to ref 128005 +line 130565 -_-_ + from ref 128773 z 1999 to ref 128005 +preferred_whz 414 544 1 +end diff --git a/uml/lumiera/132101.diagram b/uml/lumiera/132101.diagram new file mode 100644 index 000000000..39dd25211 --- /dev/null +++ b/uml/lumiera/132101.diagram @@ -0,0 +1,91 @@ +format 40 + +classinstancecanvas 128005 classinstance_ref 136069 // + xyz 144 217 2000 + end +classinstancecanvas 128133 classinstance_ref 136197 // node1 + xyz 169 309 2000 + end +classinstancecanvas 128261 classinstance_ref 136325 // node2 + xyz 485 277 2000 + end +classinstancecanvas 128389 classinstance_ref 136453 // next_adapter + xyz 388 216 2005 + end +classinstancecanvas 128901 classinstance_ref 136581 // current_state + xyz 114 20 2000 + end +classinstance 129285 class_ref 142469 // caller + name "" xyz 29 106 2000 +classinstance 129541 class_ref 142597 // Backend_Cache + name "" xyz 412 39 2000 +textcanvas 130565 "node1 using node2 as predecessor" + xyzwh 267 343 2000 133 24 +textcanvas 130693 "try to get frame from Cache first" + xyzwh 468 121 2000 89 43 +note 130821 "Triggered by pulling" + xyzwh 5 176 2005 118 38 +note 130949 "Buffers" + xyzwh 255 20 2005 61 35 +linkcanvas 128517 + from ref 128005 z 1999 to ref 128133 +dirscanvas 128645 z 1000 linkcanvas_ref 128517 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "2 pull()" xyz 217 255 3000 + backward_label "3 retrieveBuffers()" xyz 95 282 3000 +linkcanvas 128773 + from ref 128005 z 1999 to ref 128389 +dirscanvas 130053 z 1000 linkcanvas_ref 128773 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "4 create" xyz 281 192 3000 +linkcanvas 129029 + from ref 128005 z 1999 to ref 128901 +linkcanvas 129157 + from ref 128389 z 1999 to ref 128261 +dirscanvas 130309 z 1000 linkcanvas_ref 129157 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "6 pull()" xyz 515 246 3000 +linkcanvas 129413 + from ref 129285 z 1999 to ref 128005 +dirscanvas 129925 z 1000 linkcanvas_ref 129413 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "1 pull()" xyz 124 140 3000 +linkcanvas 129669 + from ref 128389 z 1999 to ref 129541 +dirscanvas 130181 z 1000 linkcanvas_ref 129669 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "5 try_fetch" xyz 386 132 3000 +linkcanvas 129797 + from ref 128005 z 1999 to ref 129541 +dirscanvas 130437 z 1000 linkcanvas_ref 129797 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "7 store" xyz 280 108 3000 +msgs + msg operation_ref 135685 // "pull(inout renderProcess : State) : void" + forward ranks 1 "1" dirscanvas_ref 129925 + msgs + msg operation_ref 135557 // "pull(inout renderProcess : State) : void" + forward ranks 2 "1.1" dirscanvas_ref 128645 + msgs + msg operation_ref 135813 // "retrieveBuffers(in requiredSource : vector const) : void" + backward ranks 3 "1.1.1" dirscanvas_ref 128645 + msgs + explicitmsg "create" + forward ranks 4 "1.1.1.1" dirscanvas_ref 130053 + msgs + explicitmsg "try_fetch" + forward ranks 5 "1.1.1.1.1" dirscanvas_ref 130181 + no_msg + msg operation_ref 135557 // "pull(inout renderProcess : State) : void" + forward ranks 6 "1.1.1.1.2" dirscanvas_ref 130309 + no_msg + msgsend + explicitmsg "store" + forward ranks 7 "1.1.1.2" dirscanvas_ref 130437 + no_msg + msgsend + msgsend + msgsend +msgsend +preferred_whz 599 408 1 +end diff --git a/uml/lumiera/5.session b/uml/lumiera/5.session index fc9677d8c..5f7a09a5a 100644 --- a/uml/lumiera/5.session +++ b/uml/lumiera/5.session @@ -1,14 +1,20 @@ window_sizes 1140 830 270 860 680 71 diagrams - active componentdiagram_ref 128005 // Overview - 702 640 80 4 2 0 + active collaborationdiagram_ref 132101 // pull call + 599 408 100 4 0 0 + classdiagram_ref 131973 // Engine Details + 414 544 100 4 0 0 + classdiagram_ref 128389 // Render Entities + 829 656 100 4 162 0 end show_stereotypes selected package_ref 129 // lumiera open - componentview_ref 128133 // interfaces - classview_ref 128005 // Session + + package_ref 128261 // MObject + classview_ref 128133 // Engine Workings + usecaseview_ref 128517 // render process class_ref 140677 // QueryHandler class_ref 140805 // TypeHandler class_ref 140933 // ResolverBase diff --git a/uml/lumiera/lumiera.prj b/uml/lumiera/lumiera.prj index dcdd63301..93cb8fa6f 100644 --- a/uml/lumiera/lumiera.prj +++ b/uml/lumiera/lumiera.prj @@ -1,6 +1,6 @@ format 40 "lumiera" - revision 44 + revision 45 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/renderengine.html b/wiki/renderengine.html index be449639b..09256ec75 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -556,10 +556,11 @@ is how to implement the relationship between [[MObject]]s and Assets. Do we use -
+
Assets are created by a Factories returning smart pointers; the Asset creation is bound to specific use cases and //only available// for these specific situations. There is no generic Asset Factory.
 
-For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file)
+For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file &rarr; LoadingMedia) + 
The Asset Manager provides an Interface to some internal Database holding all Assets in the current Session and System state. It may be a real Database at some point (and for the moment it's a Hashtable). Each [[Asset]] is registered automatically with the Asset Manager; it can be queried either by it's //identification tuple// or by it's unique ID.
@@ -752,12 +753,12 @@ Note, //we still have to work out how exactly building, rendering and playback w [img[Colaborations in the Build Process|uml/fig128517.png]]
-
+
Actually setting up and wiring a [[processing node|ProcNode]] involves several issues and is carried out at the lowest level of the build process.
-It is closely related to &rarr; [[the way nodes are operated|NodeOperationProtocol]]
+It is closely related to &rarr; [[the way nodes are operated|NodeOperationProtocol]] and the &rarr; [[mechanics of the render process|RenderMechanics]]
 
 !!!object creation
-The Nodes are small polymorphic objects, carrying configuration data, but no state. They are [[specially allocated|ManagementRenderNodes]], and the object creation is accessible solely by the NodeFactory. They //must not be deallocated manually.// The decision of what concrete node type to create depends on the actual build situation and is worked out by the combination of [[mould|BuilderMould]] and [[processing pattern|ProcPatt]] at the current OperationPoint, issuing a call to one of NodeFactory's {{{operator()}}}
+The Nodes are small polymorphic objects, carrying configuration data, but no state. They are [[specially allocated|ManagementRenderNodes]], and the object creation is accessible by means of the NodeFactory solely. They //must not be deallocated manually.// The decision of what concrete node type to create depends on the actual build situation and is worked out by the combination of [[mould|BuilderMould]] and [[processing pattern|ProcPatt]] at the current OperationPoint, issuing a call to one of NodeFactory's {{{operator()}}}
 
 !!!node, plugin and processing function
 Its a good idea to distinguish clearly between those concepts. A plugin is a piece of (possibly external) code we use to carry out operations. We have to //discover its properties and capabilities.// We don't have to discover anything regarding nodes, because we (Lumiera builder and renderengine) are creating, configuring and wiring them to fit the specific purpose. Both are to be distinguished from processing functions, which do the actual calculations on the media data. Every node typically encompasses at least one processing function, which may be an internal function in the node object, a library function from Lumiera or GAVL, or external code loaded from a plugin.
@@ -880,12 +881,12 @@ While building, the application of such a visiting tool (especially the [[NodeCr
-
+
Besides the primary working tool within the builder (namely the [[Node Creator Tool|PlanningNodeCreatorTool]]), on a lower level, we encounter several [[elementary building situations|BuilderPrimitives]] &mdash; and for each of these elementary situations we can retrieve a suitable "fitting tool" or [[mould|BuilderMould]]. The palette of these moulds is called the ''tool kit'' of the builder. It is subject to configuration by rules.
 
 
 !!addressing a mould
-All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type ({{{PipeMould}}}, {{{CombiningMould}}}, {{{SourceChainMould}}}, {{{WiringMould}}}) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
+All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type (PipeMould, CombiningMould, SourceChainMould, WiringMould) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
 
 !!configuring a mould
 As each mould kind is different, it has a {{{prepare(...)}}} function with suitably typed parameters. The rest is intended to be  self-configuring (for example, a ~CombiningMould will detect the actual kind of Transition and select the internal mode of operation), so that it's sufficient to just call {{{operate()}}}
@@ -1007,7 +1008,7 @@ This is an very important external Interface, because it links together all thre
 
[[ProcLayer and Engine]]
-
+
As detailed in the [[definition|DefaultsManagement]], {{{default(Obj)}}} is sort of a Joker along the lines "give me a suitable Object and I don't care for further details". Actually, default objects are implemented by the {{{mobject::session::DefsManager}}}, which remembers and keeps track of anything labeled as "default". This defaults manager is a singleton and can be accessed via the [[Session]] interface, meaning that the memory track regarding defaults is part of the session state. Accessing an object via the query for an default actually //tagges// this object (storing a weak ref in the ~DefsManager). Alongside with each object successfully queried via "default", the degree of constriction is remembered, i.e. the number of additional conditions contained in the query. This enables us to search for default objects starting with the most unspecific.
 
 !Skeleton
@@ -1027,7 +1028,7 @@ Taken precisely, the "degree of constriction" yields only a partial or
 {{red{WARN}}} there is an interference with the (planned) Undo function. This is a general problem of the config queries; just ignoring this issue seems reasonable.
 
 !!!Problems with the (preliminary) mock implementation
-As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see {{{MockConfigQuery}}}). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
+As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see MockConfigQuery). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
@@ -1306,7 +1307,7 @@ For this Lumiera design, we could consider making GOP just another raw media dat &rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
-
+
This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Lumiera Renderengine, the Builder and the related parts.
 
 * [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@@ -1323,6 +1324,7 @@ For this Lumiera design, we could consider making GOP just another raw media dat
 * [[integrating the Config Query system|ConfigQueryIntegration]]
 * [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreatorTool]]
 * [[how to handle »attached placement«|AttachedPlacementProblem]]
+* working out the [[basic building situations|BuilderPrimitives]] and [[mechanics of rendering|RenderMechanics]]
@@ -1679,7 +1681,7 @@ From experiences with other middle scale projects, I prefer having the test code [img[Example: Interfaces/Namespaces of the ~Session-Subsystems|uml/fig130053.png]]
-
+
Opening and accessing media files on disk poses several problems, most of which belong to the domain of Lumiera's data backend. Here, we focus on the questions related to making media data available to the EDL and the render engine. Each media will be represented by an MediaAsset object, which indeed could be a compound object (in case of MultichannelMedia). Building this asset object thus includes getting informations from the real file on disk. For delegating this to the backend, we use the following query interface:
 * {{{queryFile(char* name)}}} requests accessing the file and yields some (opaque) handle when successful.
 * {{{queryChannel(fHandle, int)}}} will then be issued in sequence with ascending index numbers, until it returns {{{NULL}}}.
@@ -1690,7 +1692,9 @@ From experiences with other middle scale projects, I prefer having the test code
 
 {{red{to be defined in more detail later...}}}
 
-{{red{how to create a test stub for this interface...?}}}
+&rarr; see "~MediaAccessFacade" for a (preliminary) interface definitioin +&rarr; see "~MediaAccessMock" for a mock/test implementaion + 
Used to actually implement the various kinds of [[Placement]] of ~MObjects. ~LocatingPin is the root of a hierarchy of different kinds of placing, constraining and locating a Media Object. Basically, this is an instance of the ''state pattern'': The user sees one Placement object with value semantics, but when the properties of the Placement are changed, actually a ~LocatingPin object (or rather a chain of ~LocatingPins) is changed within the Placement. Subclasses of ~LocatingPin implement different placing/constraining behaviour:
@@ -1762,9 +1766,11 @@ __5/2008__: the allocation mechanism can surely be improved later, but for now I
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;">loading <b>Proc-Layer</b> devel doku<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>
-
+
The Interface asset::Media is a //key abstraction// It ties together several concepts and enables to deal with them on the interfaces in a uniform manner. Besides, as every Asset kind it belongs rather to the bookkeeping view: an asset::Media holds the specific properties and parametrisation of the media source it stands for. Regarding the __inward interface__ &mdash; as used from within the [[EDL]] or the [[Render Nodes|ProcNode]], it is irrelevant if any given asset::Media object stands for a complete media source, just a clip taken from this source or if a placeholder version of the real media source is used instead.
 [img[Asset Classess|uml/fig130437.png]]
+
+&rarr; see also LoadingMedia
@@ -1824,12 +1830,12 @@ So, when creating a clip out of such a compound media asset, the clip has to be 
NodeCreaterTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the NodeCreaterTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the NodeCreaterTool creates and wires the necessary [[nodes|ProcNode]]
-
+
The [[nodes|ProcNode]] are wired to form a "Directed Acyclic Graph"; each node knows its predecessor(s), but not its successor(s).  The RenderProcess is organized according to the ''pull principle'', thus we find an operation {{{pull()}}} at the core of this process. There is no such thing as an "engine object" calling nodes iteratively or table driven, rather, the nodes themselves issue recursive calls to their predecessor(s). For this to work, we need the nodes to adhere to a specific protocol:
-# Node is pulled, providing a StateProxy object (encapsulating the access to the frames or buffers)
+# Node is pulled, with a StateProxy object as parameter (encapsulating the access to the frames or buffers)
 # Node may now access current parameter values, using the state accessible via the StateProxy
-# Node calles back into the StateProxy, providing the //input descriptor//
-# StateProxy tries to get the input frames from the Cache in the Backend. If this fails, it forwards the call using the information in the input descriptor
+# Node calles back into the StateProxy for getting the input buffer(s), providing it's //input descriptor//
+# StateProxy tries to get the input frames from the Cache in the Backend. In case of failure, the call is forwarded according to the input descriptor
 # after this call returns, the Node is allowed to dereference the frame pointers and do its calculations
 # finally, when the {{{pull()}}} call returns, the StateProxy may push down the result frames to the cache
 some points to note:
@@ -1839,7 +1845,7 @@ some points to note:
 * generally, a node may have N inputs and M output frames, which are expected to be processed in a single call
-
+
We have to consider carefully how to handle the Creation of new class instances. Because, when done naively, it can defeat all efforts of separating subsystems, or &mdash; the other extreme &mdash; lead to a //switch-on-typeID//  programming style. We strive at a solution somewhere in the middle by utilizing __Abstract Factories__ on Interface or key abstraction classes, but providing specialized overloads for the different use cases. So in each use case we have to decide if we want to create a instance of some general concept (Interface), or if we have a direct collaboration and thus need the Factory to provide a more specific sub-Interface or even a concrete type.
 
 !Object creation use cases
@@ -1850,7 +1856,8 @@ some points to note:
 |mark selection as clip|asset::Clip, session::Clip, Placement with unspec. LocatingPin| doesn't add to EDL|
 |loading Plugin|asset::Effect| usually at program startup|
 |create Session|asset::Track, asset::Pipe| |
-&rarr; [[Creating and registering Assets|AssetCreation]]
+&rarr; [[creating and registering Assets|AssetCreation]]
+&rarr; [[loading media|LoadingMedia]]
 
 !![[MObjects|MObject]]
 |add media to EDL|asset::Clip, session::Clip, Placement with unspecified LocatingPin| creating whole-media clip on-the-fly |
@@ -2628,11 +2635,11 @@ We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes and T
 //Note, we have yet to specify how exactly the building and rendering will work together with the backend. There are several possibilities how to structure the Playlist//
-
+
Open issues, Things to be worked out, Problems still to be solved... 
 
 !!Parameter Handling
-The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime.
+The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime. (&rarr; see [[tag:automation|automation]])
 
 ''Automation Type'': Directly connected is the problem of handling the //type// of parameters sensible, including the value type of automation data. My first (somewhat naive) approach was to "make everything a double". But this soon leads into quite some of the same problems haunting the automation solution implemented in the current Cinelerra codebase. What makes the issue difficult is the fact we both need static diversity as well as dynamic flexibility. Usually, when combining hierarchies and templates, one has to be very careful; so I just note the problem down at the moment and will revisit it later, when I have a more clear understanding of the demands put onto the [[ProcNode]]s
 
@@ -3019,12 +3026,35 @@ At first sight the link between asset and clip-MO is a simple logical relation b
 [img[Entities comprising the Render Engine|uml/fig128389.png]]
-
+
+
While with respect to the dependencies, the builder and the processing function, the render process is sufficiently characterized by referring to the ''pull principle'' and by defining a [[protocol|NodeOperationProtocol]] each node has to adhere to &mdash; for actually make it happen we have to care for some important details, especially //how to manage the buffers.// It may well be that the length of the code path necessary to invoke the individual processing functions is finally not so important, compared with the time spent within the inner pixel loop of these functions. But my guess is (as of 5/08), that the number of data moving and copying operations //will be//&nbsp; of importance.
+
+!reguirements
+* operations should be "in place" as much as possible
+* because caching necessitates a copy, the points where this happens should be controllable.
+* buffers should accommodate automatically to provide the necessary space without clipping the image.
+* the type of the media data can change while passing through the network, and so does the type of the buffers.
+On the other hand, the processing function within the individual node needs to be shielded from these complexities. It can expect to get just //N~~I~~// input buffers and //N~O~// output buffers of required type. And, moreover, as the decision how to organize the buffers certainly depends on non-local circumstances, it should be preconfigured while building.
+
+!data flow
+[>img[uml/fig131973.png]]
+Not everything can be preconfigured though. The pull principle opens the possibility for the node to decide on a per call base what predecessor(s) to pull (if any). This decision may rely on automation parameters, which thus need to be accessible prior to 
+requesting the buffer(s). Additionally, in a later version we plan to have the node network calculate some control values for adjusting the cache and backend timings &mdash; and of course at some point we'll want to utilize the GPU, resulting in the need to feed data from our processing buffers into some texture representation.
+
+!buffer management
+Besides the StateProxy representing the actual render process and holding a couple of buffer (refs), we employ a lightweight adapter object in between. It is used //for a single {{{pull()}}}-call// &mdash; mapping the actual buffers to the input and output port numbers of the processing node and for dealing with the cache calls. While the StateProxy manages a pool of frame buffers, this interspersed adapter allows us to either use a buffer retrieved from the cache as an input, possibly use a new buffer located within the cache as output, or (in case no caching happens) to just use the same buffer as input and output for "in-place"-processing. The idea is that most of the configuration of this adapter object is prepared in the wiring step while building the node network. 
+@@clear(right):display(block):@@
+
+
+
For each segment (of the effective timeline), there is a Processor holding the exit node(s) of a processing network, which is a "Directed Acyclic Graph" of small, preconfigured, stateless [[processing nodes|ProcNode]]. This network is operated according to the ''pull principle'', meaning that the rendering is just initiated by "pulling" output from the exit node, causing a cascade of recursive downcalls. Each node knows its predecessor(s) an can pull the necessary input from there. Consequently, there is no centralized "engine object" which may invoke nodes iteratively or table driven &mdash; rather, the rendering can be seen as a passive service provided for the backend, which may pull from the exit nodes at any time, in any order (?), and possibly multithreaded.
-All State necessary for a given calculation process is encapsulated and accessible by a StateProxy object, which can be seen as the representation of "the process". At the same time, this proxy acts as a gateway to the backend to handle the communication with the Cache.
+All State necessary for a given calculation process is encapsulated and accessible by a StateProxy object, which can be seen as the representation of "the process". At the same time, this proxy provides the buffers holding data to be processed and acts as a gateway to the backend to handle the communication with the Cache.
+
 {{red{TODO: fill in more details of the Render Process.}}}
+[img[uml/fig132101.png]]
 * see also
 &rarr; the [[Entities involved in Rendering|RenderEntities]]
+&rarr; the [[mechanics of rendering and buffer management|RenderMechanics]]
 &rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
@@ -3338,8 +3368,8 @@ h1,h2,h3,h4,h5,h6 { /*}}}*/
-
-
<<timeline better:true maxDays:55 maxEntries:30>>
+
+
<<timeline better:true maxDays:55 maxEntries:45>>
/***
@@ -4420,10 +4450,10 @@ Using transitions is a very basic task and thus needs viable support by the GUI.
 Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their "simple" counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output pipes as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a  inconsistently placed transition is just an [[building error|BuildingError]])
-
+
A ''~Meta-Clip'' or ''Virtual Clip'' (both are synonymous) denotes a clip which doesn't just pull media streams out of a source media asset, but rather provides the results of rendering a complete sub-network. In all other respects it behaves exactly like a "real" clip, i.e. it has [[source ports|ClipSourcePort]], can have attached effects (thus forming a local render pipe) and can be placed and combined with other clips. Depending on what is wired to the source ports, we get two flavours:
-* a __placeholder clip__ has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
-* a __nested EDL__ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, you'd also [[configure the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
+* a __placeholder clip__; has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
+* a __nested EDL __ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, you'd also [[configure the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
 
 Like any "real" clip, Virtual Clips have a start offset and a length, which will simply translate into an offset of the frame number pulled from the Virtual Clip's source connection or embedded EDL, making it possible to cut, splice, trim and roll them as usual. This of course implies we can have several instances of the same virtual clip with different start offset and length placed differently. The only limitation is that we can't handle cyclic dependencies for pulling data (which has to be detected and flagged as an error by the builder)