diff --git a/doc/design/architecture/playRender.txt b/doc/design/architecture/playRender.txt index 3b062d992..afcf2b61f 100644 --- a/doc/design/architecture/playRender.txt +++ b/doc/design/architecture/playRender.txt @@ -40,23 +40,23 @@ Now, we need to shorten that into a single word. The more obvious abbreviation (just by the importance) would be _Render_, but that would be strikingly misleading, because everyone would take that to be the render engine. Which leaves us with _Player_. A second -consideration shows us that the structure of that subsystem will -be very close to the structure of any software player -- the chosen term -turns out to be well aligned with the actual nature of that subsystem. +consideration highlights similarities with the structure of a +typical software player -- the chosen term turns out to be well +aligned with the actual nature of that subsystem. Influences and Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In accordance with the spirit of modern software development, the analysis starts by determining which would be the _Service_ to be provided by such -a player. Consideration of the use cases highlights the fundamental forces +a player. Consideration of the use cases determines the fundamental forces to be _multiplicity_, combined with _differentiation in detail_, all under the government of _time-bound delivery_, combined with _live reconfiguration_. The basic service turns out to be the *performing of a preconfigured object model*. This performance is *time based*. Multiple usage instances of this service can be expected to coexist, each of which can be broken down into a set of *elementary -streams to be delivered synchronously*. The delivery mode can be *reconfigured +streams to be delivered in sync*. The parameters of delivery can be *reconfigured on-the-fly*. Modes of operation diff --git a/doc/devel/rfc_pending/EngineInterfaceOverview.txt b/doc/devel/rfc_pending/EngineInterfaceOverview.txt index 7e89c4a9c..d33461893 100644 --- a/doc/devel/rfc_pending/EngineInterfaceOverview.txt +++ b/doc/devel/rfc_pending/EngineInterfaceOverview.txt @@ -1,6 +1,12 @@ +Engine Interface Overview +========================= +:Date: 2010 + +// please don't remove the //word: comments + [grid="all"] `------------`----------------------- -*State* _Idea_ +*State* _Draft_ *Date* _2010-04-16_ *Proposed by* link:Ichthyostega[] ------------------------------------- @@ -8,11 +14,14 @@ Overview Engine Interface(s) ---------------------------- + +******************************************************************************** At the Engine Interfaces, Lumiera's Backend and Session get connected and work together to produce rendered output. This design proposal intends to give an overview of the connection points and facilities involved, to define some terms and concepts and to provide a foundation for discussion and working out the APIs in detail. +******************************************************************************** @@ -26,8 +35,7 @@ Participants *Scheduler*:: cares for calculations actually to happen, in the right order and just in time, if at all *Node*:: abstraction of an processing unit, supports planning by the - dispatcher, + - allows to pull data, thereby driving the actual calculation. + dispatcher, allows to pull data, thereby driving the actual calculation. Render Process ~~~~~~~~~~~~~~ @@ -62,7 +70,7 @@ identifier and _channel selector_. timings:: a definition to translate global model time units in real clock time, - including _alignment_ to an external time grid. + including _alignment_ to an external _time grid_. model port:: a point in the (high level) model where output can be produced. + @@ -166,7 +174,7 @@ prerequisites) Node Invocation API ~~~~~~~~~~~~~~~~~~~ As nodes are stateless, they need to be embedded into an invocation context in -order to be of any use. + The node invocation has two distinct stages and thus +order to be of any use. The node invocation has two distinct stages and thus the invocation API can be partitioned in two groups Planning @@ -175,8 +183,8 @@ During the planning phase, the dispatcher retrieves various informations necessary to _schedule_ the following pull call. These informations include * reproducible invocation identifier, usable to label frames for caching - * opaque source identifier (owned by the backed) when this node represents a - source + * opaque source identifier (owned by the backed) in case this node + represents a source * prerequisite nodes * index (channel) of the prerequisite's output to be fed as input buffer(s) * number and size of the output buffers required @@ -201,11 +209,13 @@ Node pull Tasks ~~~~~ * find out if we need to support variable framerate - * find out about the exact handling of multichannel data streams - * design a buffer descriptor - * design a buffer designation scheme - * expand on the node identification scheme - * clarify how control data frames can be addressed + ([green]#-> yes, implementation deferred#) + * find out about the exact handling of multichannel data streams ([green]#✔ done#) + * design and prototypical implementation of frame quantisation ([green]#✔ done#) + * design a buffer descriptor [red]#TODO# + * design a buffer designation scheme [red]#TODO# + * expand on the node identification scheme [red]#TODO# + * clarify how control data frames can be addressed [red]#TODO# Discussion @@ -229,17 +239,28 @@ Rationale +//Conclusion +//---------- +//conclusion: When approbate (this proposal becomes a Final) +// write some conclusions about its process: + + + Comments -------- +//comments: append below -//////////////////// +.State -> Draft +Requirements and details of the design are sufficiently clear meanwhile. +Ther seems to be not much room for alternative approaches, given our +general planning for the application -Conclusion -~~~~~~~~~~ -* *accepted* / *dropped* by MMMMMM.YYYY developer meeting. - -//////////////////// + Mi 11 Mai 2011 19:27:12 CEST Ichthyostega +//endof_comments: + +'''' Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] +