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

linked to some new diagrams; explanation of Automation and Builder implementation

Browse source
This commit is contained in:
Fischlurch 2007-06-25 09:56:36 +02:00
parent 139ced45f7
commit a48bcf2f40
2 changed files with 48 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
uml/cinelerra3/128901
View file

@ -1,6 +1,6 @@
format 38
"Builder" // MObject::Builder
revision 6
"Builder" // ProcessingLayer::MObject::Builder
revision 7
modified_by 5 "hiv"
// class settings
//class diagram settings
@ -226,7 +226,7 @@ ${inlines}
classrelation 137221 // <dependency>
relation 135685 -_->
a default
cpp default "Generated"
cpp default "#include in header"
classrelation_ref 137221 // <dependency>
b multiplicity "" parent class_ref 134149 // Tool
end
@ -425,7 +425,7 @@ ${inlines}
end
end
class 134405 "NodeCratorTool"
class 134405 "NodeCreatorTool"
visibility package
cpp_decl "${comment}${template}class ${name}${inherit} {
${members}};

51
wiki/renderengine.html
View file

@ -635,6 +635,11 @@ ColorPalette
SiteUrl</pre>
</div>
<div title="Automation" modifier="Ichthyostega" created="200706250751" changecount="1">
<pre>Automation is treated as a function over time. It is always tied to a specific Parameter (which can thus be variable over the course of the timeline). All details //how// this function is defined are completely abstracted away. The Parameter uses a ParamProvider to get the value for a given Time (point). Typically, this will use linear or bezier interpolation over a set of keyframes internally. Parameters can be configured to have different value ranges and distribution types (on-off, stepped, continuous, bounded)
[img[how to implement Automation|uml/fig129669.png]]</pre>
</div>
<div title="BetterTimelineMacro" modifier="Saq" modified="200701030924" created="200607280926" tags="lewcidExtension systemConfig" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200701030924">
<pre>/***
|Name|BetterTimelineMacro|
@ -747,10 +752,19 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
}
//}}}</pre>
</div>
<div title="BuildProcess" modifier="Ichthyostega" modified="200706231630" created="200706190658" tags="dynamic" changecount="7">
<div title="BuildProcess" modifier="Ichthyostega" modified="200706250744" created="200706190658" tags="dynamic" changecount="15">
<pre>All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actuall performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &amp;mdash; to pay in the Builder &amp;mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
[&gt;img[Outline of the Build Process|uml/fig129413.png]]
The building itself will be broken down into several small tool application steps. Each of this steps has to be mapped on the MObjects found in the [[Timeline]]. Remember: the idea is that this so called &quot;[[Fixture]]&quot; contains only [[ExplicitePlacement]]s which in turn link to MObjects like Clips, Effects and Automation. So it is sufficient to traverse this list and map the build tools on the elements. Each of this build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
* find the &quot;Segments&quot;, i.e. the locations where the overall configuration changes
* for each segment: generate a ProcNode for each found MObject and wire them accordingly
Note, //we have still to work out how exactly building, rendering and playback work// together with the backend-design. But the build process as such doesnt't overly depend on this decisions, it is easy to reconfigure this process. For example, it would be possible as well to build for each frame separately (as Cinelerra2 does), or to build one segment covering the whole timeline (and handle everything via [[Automation]]
&amp;rarr;see also: BuilderStructures
[img[Colaborations in the Build Process|uml/fig128517.png]]
</pre>
</div>
<div title="Builder" modifier="Ichthyostega" created="200706220317" tags="def" changecount="2">
@ -759,6 +773,21 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
The Builder is part of the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]
</pre>
</div>
<div title="BuilderStructures" modifier="Ichthyostega" modified="200706250743" created="200706250734" changecount="5">
<pre>* the MObjects implement //Buildable//
* each Buildable can &quot;recieve&quot; a Tool object and aply it
* the different Tool objects are iterated/mapped onto the list of MObjects in the [[Timeline]]
* __Rationale__
* the MObject class hierarchy is rather fixed (it is unlikely the we will be adding much new MObject subclasses)
* so this design makes it easy to add new Tool subclasses, and within each Tool subclass, all operations on the different MObject classes are grouped together, so it is easy to see what is going on.
* a given Tool instance can carry state while beeing iterated, so we don't need any global (or object-global) variables to hold the result of the build process
This programming technique is often refered to as //double dispatch// or //visitor//
{{red{TODO:flesh out the actual Operations needed}}}
[img[Entities cooperating in the Builder|uml/fig129285.png]]</pre>
</div>
<div title="ColorPalette" modifier="Ichthyostega" modified="200706190041" created="200706190033" changecount="9">
<pre>Background: #fefefd
Foreground: #000
@ -1341,7 +1370,7 @@ see also: RenderEntities
&lt;!--}}}--&gt;
</pre>
</div>
<div title="ParamProvider" modifier="Ichthyostega" created="200706220517" tags="def" changecount="5">
<div title="ParamProvider" modifier="Ichthyostega" modified="200706250752" created="200706220517" tags="def" changecount="6">
<pre>A ParamProvider is the counterpart for (one or many) Parameter instances. It implements the value access function made available by the Parameter object to its clients.
To give a concrete example:
@ -1350,7 +1379,8 @@ To give a concrete example:
* this Parameter Object provides a getValue() function, which is internally linked (i.e. by configuration) to a //Parameter Provider//
* the actual object implementing the ParamProvider Interface could be a Automation MObject located somewhere in the EDL and would do bezier interpolation on a given keyframe set.
* while building the Render Engine configuration actually at work, the Builder would have to setup this link between the Plugin Parameter Object and the ParamProvider; he can do so, because he sees the link between the Automation MObject and the corresponding Effect MObject
</pre>
&amp;rarr; see the class diagram for [[Automation]]</pre>
</div>
<div title="Parameters" modifier="Ichthyostega" modified="200706220506" created="200706220505" tags="def" changecount="2">
<pre>Parameters are all probably variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application state to take effect.
@ -1864,8 +1894,10 @@ DAMAGE.
<pre>A Placement represents a //relation:// it is always linked to a //Subject// (this beeing a [[Media Object|MObject]]) and has the meaning to //place// this Subject in some manner, either relatively to other Media Objects, or by some Constraint or simply absolute at (time,track). The latter case is especially important and represented by a special [[Sub-Interface|ExplicitePlacement]]
</pre>
</div>
<div title="Playlist" modifier="Ichthyostega" created="200706220456" tags="def" changecount="2">
<pre>Playlist is the name of a specific facility located in the [[Fixture]] (EDL): It is a ordered list of ExplicitePlacement.s of MObjects. By traversing the Playlist you get at all elements actually to be rendered; the [[Builder]] uses this Playlist to construct actual Render Engine configurations to carry out the calculations.
<div title="Playlist" modifier="Ichthyostega" modified="200706250727" created="200706220456" tags="def" changecount="3">
<pre>Playlist is a sequence of individual Render Engine Processors able to render a segment of the timeline. So, together these Processors are able to render the whole timeline (or part of the timeline if only a part has to be rendered).
//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//
</pre>
</div>
<div title="PrimaryDark" modifier="just me" created="200706220427" changecount="1">
@ -2098,7 +2130,7 @@ config.macros.rssFeedUpdate = {
//}}}
</pre>
</div>
<div title="RenderEngine" modifier="Ichthyostega" modified="200706220524" created="200706190056" tags="overview" changecount="35">
<div title="RenderEngine" modifier="Ichthyostega" modified="200706250753" created="200706190056" tags="overview" changecount="36">
<pre>The Render Engine is the part of the application doing the actual video calculations. Its operations are guided by the Objects and Parameters edited by the user in [[the EDL|EDL]] and it retrieves the raw audio and video data from the [[Data backend|backend.html]]. Because the inner workings of the Render Engine are closely related to the structures used in the EDL, this design covers [[this aspect|MObjects]] as well.
The key idea of Ichthyo's Design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder.
@ -2121,7 +2153,7 @@ The design of Cinelerra 2 basically follows this design, but __fails because of
&amp;rarr; BuildProcess
&amp;rarr; RenderProcess
&amp;rarr; [[Two Examples|Examples]] (Object diagrams)
&amp;rarr; how [[Automation]] works {{red{to be defined}}}
&amp;rarr; how [[Automation]] works {{red{to be defined in more detail}}}
</pre>
</div>
<div title="RenderEntities" modifier="Ichthyostega" modified="200706220406" created="200706190715" changecount="6">
@ -3450,6 +3482,11 @@ function addKeyDownHandlers(e)
<div title="TiddlyWiki" modifier="Ichthyostega" created="200706220430" changecount="1">
<pre>http://tiddlywiki.com/</pre>
</div>
<div title="Timeline" modifier="Ichthyostega" created="200706250721" tags="def" changecount="1">
<pre>Timeline is the name of a specific facility located in the [[Fixture]] (EDL): It is a ordered list of ExplicitePlacement.s of MObjects. By traversing the Playlist you get at all elements actually to be rendered; the [[Builder]] uses this Timeline-list to construct actual Render Engine configurations to carry out the calculations.
</pre>
</div>
<div title="WalkThrough" modifier="Ichthyostega" modified="200706220359" created="200706210625" tags="overview" changecount="28">
<pre>The Intention of this text is to help you understanding the design and to show some notable details.