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

review and verify lib::ElementTracker

Browse source
This commit is contained in:
Fischlurch 2010-10-18 05:33:46 +02:00
parent 884e3600bd
commit 3e9c337ac0
5 changed files with 19 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
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 utilize lumiera::P or a
** the instance lifecycle handling is assumed to utilise 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
@ -45,7 +45,7 @@
** segfault on application shutdown. ///TICKET #574
**
** @see session-element-tracker-test.cpp
** @see session-interface-modules
** @see session-interface-modules.hpp
** @see Timeline
** @see Sequence
**
@ -105,7 +105,7 @@ namespace lib {
{
_Vec toKill;
toKill.reserve(_Vec::size());
toKill.swap(*this);
toKill.swap(*this); // prevent quadratic detach()
ASSERT (0 == _Vec::size());
util::for_each (toKill, unlink_it);
}

6
src/proc/mobject/session/session-interface-modules.hpp
View file

@ -39,6 +39,8 @@
** located directly below model root.
** - likewise there is an table of all Sequence (structural assets), which
** correspond to the roots of track trees, attached below model root.
** - the ElementQuery interface allows to retrieve specific object
** instances by applying a filter predicate.
**
** \par maintaining the link between session, timelines and sequences
**
@ -53,10 +55,10 @@
** are completely dependent.
** In any case, ctor and dtor of Timeline and Sequence have to care for proper
** registration into the SessionInterfaceModules for timelines and sequences
** respectively. This is accomplished by using kind-of a backdoor, a SessionServices
** respectively. This is accomplished by using kind-of a backdoor, a SessionServices (???)
** (proc internal API) definition, allowing direct communication on implementation
** level, without the need to expose this access point on the public session API.
** The impl::ElementTracker implemented in this sourcefile here relieves these
** The lib::ElementTracker configured in ( ??? ) receives these
** calls to maintain a list of asset smart-ptrs
**
** @see SessionImpl

2
src/proc/mobject/session/session-service-defaults.hpp
View file

@ -22,7 +22,7 @@
/** @file session-service-defaults.hpp
** Implementation level session API: manage default configured objects.
** Implementation level session API: to manage default configured objects.
**
** @todo rework the existing DefsManager to fit into this scheme. TICKET #404
**

6
tests/components/proc/mobject/session/session-element-tracker-test.cpp
View file

@ -110,7 +110,7 @@ namespace test {
run (Arg)
{
verify_trackingMechanism();
// verify_integration(); ///////////////////////////////////////////TICKET #499
// verify_integration(); ///////////////////////////////////////////TICKET #571
}
@ -185,7 +185,7 @@ namespace test {
PTimeline specialTimeline (asset::Struct::create (Query<Timeline> ("id(testical)")));
CHECK (specialTimeline);
CHECK (num_timelines + 1 == sess->timelines.size());
CHECK (specialTimeline == sess->timelines[num_timelines]);
CHECK (specialTimeline == sess->timelines[num_timelines]); // got appended at the end of the tracking table
CHECK (specialTimeline.use_count() == 3); // we, the AssetManager and the session
PTimeline anotherTimeline (asset::Struct::create (Query<Timeline> ()));
@ -195,7 +195,7 @@ namespace test {
AssetManager& assetM (AssetManager::instance());
CHECK (assetM.known (specialTimeline->getID()));
assetM.remove (specialTimeline->getID()); //////////////TICKET #550
assetM.remove (specialTimeline->getID()); //////////////TICKET #550 modalities of Timeline/Sequence deletion
CHECK (!assetM.known (specialTimeline->getID()));
CHECK (num_timelines + 1 == sess->timelines.size());

15
wiki/renderengine.html
View file

@ -2519,14 +2519,15 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
[img[Classess related to the session|uml/fig128133.png]]
</pre>
</div>
<div title="MagicAttachment" modifier="Ichthyostega" created="201006132135" tags="Model spec draft" changecount="1">
<div title="MagicAttachment" modifier="Ichthyostega" modified="201010180131" created="201006132135" tags="Model spec draft" changecount="3">
<pre>The HighLevelModel consists of MObjects, which are attached to one another through their [[Placement]]. While this is a generic scheme to arrange objects in a tree of [[scopes|PlacementScope]], some attachments are handled specifically and may trigger side-effects
{{red{drafted feature as of 6/2010}}}
* a [[binding|BindingMO]] attached to root is linked to a [[Timeline]]
* a [[Track]] attached to rood corresponds to a [[Sequence]]
</pre>
* a [[Track]] attached to root corresponds to a [[Sequence]]
&amp;rarr; see ModelDependencies</pre>
</div>
<div title="MainMenu" modifier="Ichthyostega" modified="200802031758" created="200706172305" changecount="10">
<pre>''[[Lumiera|index.html]]''
@ -4497,10 +4498,10 @@ We need to detect attaching and detaching of
* root &amp;harr; [[Track]]
</pre>
</div>
<div title="Sequence" modifier="Ichthyostega" modified="201006132117" created="201001252327" tags="def" changecount="15">
<div title="Sequence" modifier="Ichthyostega" modified="201010180156" created="201001252327" tags="def" changecount="17">
<pre>A sequence is a collection of media objects, arranged onto a track tree. Sequences are the building blocks within the session. To be visible and editable, a session needs to be bound into a top-level [[Timeline]]. Alternatively, it may be used as a VirtualClip nested within another sequence.
The sequences within the session establish a //logical grouping//, allowing for lots of flexibility. Actually, we can have several sequences within one session, and these sequences can be linked together or not, they may be arranged in temporal order or may constitute a logical grouping of clips used simultaneously in compositional work etc. The data structure comprising a sequence is always a sub-tree of tracks, attached allways directly below root (Sequences at sub-nodes are deliberately disallowed). Through the sequence as frontend, this track tree might be used at various places in the model simultaneously. Tracks in turn are only an organisational (grouping) devices, like folders, so this structure of sequences and track trees referred through them allows to use the contents of such a track or folder at various places within the model. But at any time, we have exactly one [[Fixture]], derived automatically from all sequences and containing the content actually to be rendered.
The sequences within the session establish a //logical grouping//, allowing for lots of flexibility. Actually, we can have several sequences within one session, and these sequences can be linked together or not, they may be arranged in temporal order or may constitute a logical grouping of clips used simultaneously in compositional work etc. The data structure comprising a sequence is always a sub-tree of tracks, attached allways directly below root (Sequences at sub-nodes are deliberately disallowed). Through the sequence as frontend, this track tree might be used at various places in the model simultaneously. Tracks in turn are only an organisational (grouping) device, like folders &amp;mdash; so this structure of sequences and track trees referred through them allows to use the contents of such a track or folder at various places within the model. But at any time, we have exactly one [[Fixture]], derived automatically from all sequences and containing the content actually to be rendered.
&amp;rarr; see considerations about [[the role of Tracks and Pipes in conjunction with the sequences|TrackPipeSequence]]
!!Implementation and lifecycle
@ -6270,10 +6271,10 @@ function addKeyDownHandlers(e)
<div title="TiddlyWiki" modifier="Ichthyostega" created="200706220430" changecount="1">
<pre>http://tiddlywiki.com/</pre>
</div>
<div title="Timeline" modifier="Ichthyostega" modified="201003020524" created="200706250721" tags="def" changecount="16">
<div title="Timeline" modifier="Ichthyostega" modified="201010180151" created="200706250721" tags="def" changecount="17">
<pre>Timeline is the top level element within the [[Session (Project)|Session]]. It is visible within a //timeline view// in the GUI and represents the effective (resulting) arrangement of media objects, to be rendered for output or viewed in a Monitor (viewer window). A timeline is comprised of:
* a time axis in abolute time ({{red{WIP 1/10}}}: not clear if this is an entity or just a conceptual definition)
* a PlayControler
* a PlayControler ({{red{WIP Summer 2010: see discussion on ML. It seems rather that the controller will be attached}}})
* a list of global Pipes representing the possible outputs (master busses)
* //exactly one// top-level [[Sequence]], which in turn may contain further nested Sequences.
Please note especially that following this design //a timeline doesn't define tracks.// [[Tracks form a Tree|Track]] and are part of the individual sequences, together with the media objects placed to these tracks.