benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

some explanatory writing

Browse source
This commit is contained in:
Fischlurch 2007-06-21 19:39:49 +02:00
parent 2fce71d226
commit 21651021aa
1 changed files with 20 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
wiki/ichthyo-draft.html
View file

@ -2010,7 +2010,7 @@ see : <<tag RSSFeed>> for the full list.
</pre> </pre>
</div> </div>
<div title="RenderEngine" modifier="Ichthyostega" modified="200706210608" created="200706190056" changecount="20"> <div title="RenderEngine" modifier="Ichthyostega" modified="200706211728" created="200706190056" changecount="25">
<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. <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. 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.
@ -2018,22 +2018,21 @@ The key idea of Ichthyo's Design-draft is to use the [[Builder Pattern|http://en
!Why doesn't the current Design succeed with this? !Why doesn't the current Design succeed with this?
The design of Cinelerra 2 basically follows this design, but __fails because of two reasons__ The design of Cinelerra 2 basically follows this design, but __fails because of two reasons__
* too much differentiation is put into the class hierarchy instead of configuring Instances differently. # too much differentiation is put into the class hierarchy instead of configuring Instances differently.&lt;br&gt;This causes overly heavy use of virtual functions and -- in order to ameliorate this -- falling back to hard wired branching
This causes overly heavy use of virtual functions and -- in order to ameliorate this -- falling back to hard wired branching # far too much back-coupling to the internals of the [[EDL]], forcing a overly rigid structure on the latter
* far too much back-coupling to the internals of the [[EDL]], forcing a overly rigid structure on the latter
!Try to learn from this !Try to learn from this
* build up an NodeAbstraction powerful enough to express //all necessary Operations// without the need to recure on the actual object type * build up an NodeAbstraction powerful enough to express //all necessary Operations// without the need to recure on the actual object type
* need to redesign the internals of the EDL in a far more open manner. See MObjects * need to redesign the internals of the EDL in a far more open manner. See MObjects
* strive at a StrongSeparation between EDL and Render Engine * strive at a StrongSeparation between EDL and Render Engine
!!see also !!see also
* [[Overview]] of Subsystems and Components, and DesignGoals &amp;rarr; [[Overview]] of Subsystems and Components, and DesignGoals
* [[An Introduction|WalkThrough]] discussing the key features {{red{TODO}}} &amp;rarr; [[An Introduction|WalkThrough]] discussing the key features {{red{TODO}}}
* [[Overview Render Engine|OverviewRenderEngine]] &amp;rarr; [[Overview Render Engine|OverviewRenderEngine]]
* BuildProcess &amp;rarr; BuildProcess
* RenderProcess &amp;rarr; RenderProcess
* [[Two Examples|Examples]] (Object diagrams) {{red{TODO: write explanation for the drawings in UML}}}</pre> &amp;rarr; [[Two Examples|Examples]] (Object diagrams) {{red{TODO: write explanation for the drawings in UML}}}</pre>
</div> </div>
<div title="RenderEntities" modifier="Ichthyostega" modified="200706210631" created="200706190715" changecount="3"> <div title="RenderEntities" modifier="Ichthyostega" modified="200706210631" created="200706190715" changecount="3">
<pre>The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of ProcessingNodes discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations. <pre>The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of ProcessingNodes discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
@ -3306,8 +3305,14 @@ function addKeyDownHandlers(e)
} }
//}}}</pre> //}}}</pre>
</div> </div>
<div title="WalkThrough" modifier="Ichthyostega" created="200706210625" changecount="1"> <div title="WalkThrough" modifier="Ichthyostega" modified="200706211738" created="200706210625" changecount="11">
<pre>The Intention of this text is to help you understanding the design and to show some notable details. {{red{To be written}}}</pre> <pre>The Intention of this text is to help you understanding the design and to show some notable details. {{red{To be written}}}
!!!!Design is an experiment to find out how things are related
We can't //plan// a Design top down, rather we have to start at some point with some hypothesis and look how it works out. The point of departure for Ichthyo's design is the observation, that the Render Engine needs some Separation of Concearns to get the complexity down. And especially, this design ''uses three different Levels'' or Layers within the Render Engine and EDL.
* the __high level__ within the EDL uses uniformely treated MObjects which are assembled/glued together by a network of [[Placements]].&lt;br&gt; It is supposed that the GUI will present this and //only this view// to the user, giving him the ability wo work with this objects
* the __builder level__ works on a stripped-down subset of this ~MObject network: it uses the //same Object instances// but only assembled by ExplicitePlacements which locate the objects //on a simple (track, time) grid.// Its the builders job to create out of this simplified Network the Configuration of RenderNodes needed to do the actual rendering
* the __engine level__ uses solely Render Pipeline Nodes, i.e. a Graph of interconnected processing nodes. The important constraint here is that //any decisions are ruled out//. The core Render Engine with all its nodes is lacking the ability to do any tests and checks and has no possibility to branch or reconfigure anything. (this is an especially important lession I draw from studying the current Cinelerra source code)</pre>
</div> </div>
</div> </div>
<!--POST-STOREAREA--> <!--POST-STOREAREA-->