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

re-reading my design and plannings from March, identiyfying next steps to take

Browse source
This commit is contained in:
Fischlurch 2010-06-13 03:34:12 +02:00
parent e574fdf702
commit fc3e43bb19
3 changed files with 9 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/lib/element-tracker.hpp
View file

@ -26,7 +26,7 @@
** These helper templates can be used to provide a registry of all objects
** of some kind or type. The class to be used with instance tracking needs
** to cooperate, typically by inheriting from lib::AutoRegistered. Moreover,
** the instance lifecycle handling is assumed to utilise lumiera::P or a
** the instance lifecycle handling is assumed to utilize lumiera::P or a
** similar smart-ptr, which allows the registry to hold a safe reference.
** Thus, references won't be cleaned up automatically (as there is always
** at least one reference left) -- rather we rely on invoking a dispose or

2
tests/components/proc/asset/typed-id-test.cpp
View file

@ -58,7 +58,7 @@ namespace mobject {
namespace session {
namespace test {
struct DummyEntity { };
struct DummyEntity { }; ////////////////////////TODO of course the key idea is to mix in TypedID::link, to get an automatic registration and deregistartion
typedef lumiera::P<DummyEntity> PDum;

10
wiki/renderengine.html
View file

@ -604,7 +604,7 @@ Generally speaking, assets can be seen as the statical part or view of the sessi
Conceptually, assets belong to the [[global or root scope|ModelRootMO]] of the session data model. A mechanism for serialising and de-serialising all assets alongside with the session is planned as of 2/2010
</pre>
</div>
<div title="AssetModelConnection" modifier="Ichthyostega" modified="201003200149" created="201003160243" tags="SessionLogic Model spec draft discuss" changecount="3">
<div title="AssetModelConnection" modifier="Ichthyostega" modified="201006130132" created="201003160243" tags="SessionLogic Model spec draft discuss img" changecount="4">
<pre>Conceptually, Assets and ~MObjects represent different views onto the same entities. Assets focus on bookkeeping of the contents, while the media objects allow manipulation and EditingOperations. Usually, on the implementation side, such closely linked dual views require careful consideration.
!redundancy
@ -616,6 +616,9 @@ Obviously there is the danger of getting each entity twice, as Asset and as ~MOb
* tracks are completely deprived of processing functionality and become lightweight containers, also used as clip bins.
* timelines and sequences are implemented as façade to equivalent structures within the model
* this leaves us only with effects requiring both an object and asset implementation
[&lt;img[Fundamental object relations used in the session|uml/fig138885.png]]
</pre>
</div>
<div title="AttachedPlacementProblem" modifier="Ichthyostega" modified="200905310342" created="200801111305" tags="SessionLogic impl draft operational" changecount="17">
@ -2358,7 +2361,7 @@ And, last but not least, doing large scale allocations is the job of the backend
<div title="Model" modifier="Ichthyostega" modified="201003210021" created="201003210020" tags="overview" changecount="2">
<pre>Lumiera's Proc-Layer is built around //two interconnected models,// mediated by the [[Builder]]. Basically, the &amp;rarr;[[Session]] is an external interface to the HighLevelModel, while the &amp;rarr;RenderEngine operates the structures of the LowLevelModel.</pre>
</div>
<div title="ModelDependencies" modifier="Ichthyostega" modified="201003220007" created="201003020150" tags="SessionLogic operational spec draft" changecount="31">
<div title="ModelDependencies" modifier="Ichthyostega" modified="201006130130" created="201003020150" tags="SessionLogic operational spec draft img" changecount="32">
<pre>Our design of the models (both [[high-level|HighLevelModel]] and [[low-level|LowLevelModel]]) relies partially on dependent objects being kept consitently in sync. Currently (2/2010), __ichthyo__'s assessment is to consider this topic not important and pervasive enough to justify building a dedicated solution, like e.g. a central tracking and registration service. An important point to consider with this assesment is the fact that the session implementation is beeing kept mostly single-threaded. Thus, lacking one central place to handle this issue, care has to be taken to capture and treat all the relevant individual dependencies properly at the implementation level.
!known interdependencies
@ -6029,7 +6032,7 @@ Just an ''registration scheme'' should be implemented right now, working complet
see [[implementation planning|TypedLookup]]
</pre>
</div>
<div title="TypedLookup" modifier="Ichthyostega" modified="201004031616" created="201004031607" tags="Rules spec impl draft" changecount="14">
<div title="TypedLookup" modifier="Ichthyostega" modified="201006130130" created="201004031607" tags="Rules spec impl draft" changecount="15">
<pre>TypedID is a registration service to associate object identities, symbolic identifiers and types. It acts as frontend to the TypedLookup service within Proc-Layer, at the implementation level. While TypedID works within a strictly typed context, this type information is translated into an internal index on passing over to the implementation, which manages a set of tables containing base entries with an combined symbolic+hash ID, plus an opaque buffer. Thus, the strictly typed context is required to re-access the stored data. But the type information wasn't erased entirely, so this typed context can be re-gained with the help of an internal type index. All of this is considered implementation detail and may be subject to change without further notice; any access is assumed to happen through the TypedID frontend. Besides, there are two more specialised frontends.
!Front-ends
@ -6052,6 +6055,7 @@ In most cases, the //actually usable instance// of an entity isn't identical to
* Plain ''~MObjects'' are somewhat similar, but there is no active lifecycle management &amp;mdash; they are always tied either to a placement of linked from within the assets or render processes. When done, they just go out of scope. Thus we too use a ''weak reference'' here, assumed the respective entity has mixed in {{{TypedID::Link}}}
* Active ''Placements'' of an MObject behave like //object instances// within the model/session. They live within the PlacementIndex and cary an unique {{{LUID}}}-ID. Thus, it's sufficient to store this ''Placement-ID'', which can be used by the access functor to fetch the corresponding Placement from the session.
Obviously, the ~TypedLookup system is open for addition of completely separate and different types.
[&gt;img[TypedLookup implementation sketch|uml/fig140293.png]]
|&gt;| !Entity |!pattern |
|1:1| Track|Placement|
|~| Label|Placement|