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

recast the PlacementHierarchy_test to use the real Placement/MObject hierarchy

Browse source
This commit is contained in:
Fischlurch 2009-05-29 23:13:56 +02:00
parent 50a42e5104
commit 20a1268683
5 changed files with 87 additions and 147 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
src/proc/mobject/builder/buildertool.hpp
View file

@ -116,8 +116,8 @@ namespace mobject {
{
currentWrapper_ = ptr_toWrappedTarget;
}
template<class TAR>
void rememberWrapper (Placement<TAR>* ptr_toWrappedTarget)
template<template<class,class> class Placement, class TAR, class B>
void rememberWrapper (Placement<TAR,B>* ptr_toWrappedTarget)
{
currentWrapper_ = ptr_toWrappedTarget;
}

4
tests/components/proc/mobject/builder/buildertooltest.cpp
View file

@ -113,8 +113,8 @@ namespace test {
BuilderTool& tool = t1;
Placement<Clip> clip = asset::Media::create("test-1", asset::VIDEO)->createClip();
TestPlacement<MObject> test1(*new TestSubMO1);
TestPlacement<MObject> test2(*new TestSubMO2);
TestPlacement<> test1(*new TestSubMO1);
TestPlacement<> test2(*new TestSubMO2);
cout << "apply (tool, clip);\n";

142
tests/components/proc/mobject/placement-hierarchy-test.cpp
View file

@ -29,6 +29,7 @@
//#include "proc/mobject/placement.hpp"
//#include "proc/mobject/placement-ref.hpp"
//#include "proc/mobject/explicitplacement.hpp"
#include "proc/mobject/test-dummy-mobject.hpp"
#include "lib/hash-indexed.hpp"
#include "lib/util.hpp"
@ -52,128 +53,7 @@ namespace mobject {
namespace session {
namespace test {
/**
* a dummy version of the MObject hierarchy,
* used to experiment with the Placement template structure
*/
struct MOj;
template<class TY, class B =MOj>
class Pla;
template<>
class Pla<MOj,MOj>
: protected shared_ptr<MOj>,
public HashIndexed<Pla<MOj>, lib::hash::LuidH> //////TODO: really need to be inherited publicly?
{
protected:
typedef shared_ptr<MOj> Base;
typedef void (*Deleter)(MOj*);
Pla (MOj & subject, Deleter killer)
: Base (&subject, killer) {};
friend class MOjFac;
public:
virtual MOj *
operator-> () const
{
ENSURE (*this);
return Base::operator-> ();
}
size_t use_count() const { return Base::use_count(); }
virtual ~Pla() {};
};
template<class TY, class B>
class Pla
: public Pla<B>
{
protected:
typedef Pla<B> _Par;
typedef typename _Par::Base Base;
typedef typename _Par::Deleter Deleter;
Pla (TY & mo, Deleter killer)
: _Par (mo, killer)
{ };
friend class MOjFac;
public:
virtual TY*
operator-> () const
{
ENSURE (INSTANCEOF (TY, this->get()));
return static_cast<TY*>
(Base::operator-> ());
}
};
string
format_PlacementID (Pla<MOj> const& pla)
{
static format fmt ("pID(%x)");
size_t hashVal = pla.getID();
return str(fmt % hashVal);
}
class MOjFac;
struct MOj
{
static MOjFac create;
int id_;
MOj() : id_(rand() % 1000) {}
virtual ~MOj() {}
void show() { cout << "ID=" << id_ << "\n"; }
};
struct Sub1 : MOj { };
struct Sub2 : MOj
{
void specialAPI() { cout << "specialAPI()\n";}
};
struct Sub3 : Sub2
{
};
class MOjFac
{
static void deleterFunc (MOj* o) { delete o; }
public:
template<class MO>
Pla<MO>
special ()
{
return Pla<MO> (*new MO, &deleterFunc);
}
typedef Pla<Sub3,Sub2> Pla3;
Pla3
specialSub3 ()
{
return Pla3 (*new Sub3, &deleterFunc);
}
};
MOjFac MOj::create;
using namespace mobject::test;
/*******************************************************************************
@ -190,11 +70,11 @@ namespace test {
virtual void
run (Arg)
{
Pla<Sub1> pSub1 = MOj::create.special<Sub1>();
Pla<Sub2> pSub2 = MOj::create.special<Sub2>();
Pla<Sub2> pSub3 = MOj::create.specialSub3();
TestPlacement<TestSubMO1> pSub1(*new TestSubMO1);
TestPlacement<TestSubMO2> pSub2(*new TestSubMO2);
TestPlacement<TestSubMO21> pSub3(*new TestSubMO21);
Pla<MOj> pSubM (pSub3);
TestPlacement<DummyMO> pSubM (pSub3);
/////////////////////////////////TODO
format fmt ("sizeof( %s ) = %d\n");
@ -202,10 +82,12 @@ namespace test {
cout << fmt % "Pla<Sub2>" % sizeof(pSub2);
cout << fmt % "Pla<Sub3>" % sizeof(pSub3);
pSub1->show();
pSub2->show();
pSub3->show();
pSubM->show();
cout << string(pSub1) << "\n";
cout << string(pSub2) << "\n";
cout << string(pSubM) << "\n";
cout << pSub1->operator string() << "\n";
cout << pSub2->operator string() << "\n";
cout << pSubM->operator string() << "\n";
pSub3->specialAPI();
cout << format_PlacementID(pSub1) << "\n";

69
tests/components/proc/mobject/test-dummy-mobject.hpp
View file

@ -43,12 +43,17 @@
#include "proc/mobject/builder/buildertool.hpp"
#include "proc/mobject/session/abstractmo.hpp"
#include "proc/mobject/placement.hpp"
#include "include/symbol.hpp"
#include "lib/util.hpp"
#include <boost/format.hpp>
#include <iostream>
#include <cstdlib>
using boost::format;
using util::cStr;
using std::string;
using std::rand;
using std::cout;
@ -56,6 +61,7 @@ using std::cout;
namespace mobject {
namespace test {
using lumiera::Symbol;
using builder::BuilderTool;
@ -65,42 +71,87 @@ namespace test {
*/
class DummyMO : public session::AbstractMO
{
int id_;
public:
DummyMO() { };
DummyMO() : id_(rand() % 1000) {}
DummyMO(int i) : id_(i) {}
DEFINE_PROCESSABLE_BY (BuilderTool);
virtual bool isValid() const { return true;}
virtual bool isValid() const { return true;}
virtual operator string() const { return display("DummyMO"); }
static void killDummy (MObject* dum) { delete (DummyMO*)dum; }
protected:
string
display(Symbol name) const
{
static format fmt("%s(ID=%4d)");
return boost::str(fmt % name % this->id_);
}
};
/**
* Subclass-1 is \em not defined "processible",
* thus will always be handled as DummyMO...
*/
class TestSubMO1 : public DummyMO
{ };
struct TestSubMO1 : DummyMO
{
virtual operator string() const { return display("TestSubMO1"); }
};
/**
* Subclass-2 \em is defined "processible",
* but we omit the necessary "applicable" definition in TestTool,
* resulting in an invocation of the error (catch-all) function...
*/
class TestSubMO2 : public DummyMO
struct TestSubMO2 : DummyMO
{
DEFINE_PROCESSABLE_BY (BuilderTool);
virtual operator string() const { return display("TestSubMO2"); }
};
struct TestSubMO21 : TestSubMO2
{
virtual operator string() const { return display("TestSubMO21"); }
void specialAPI() { cout << "specialAPI()\n";}
};
template<class MO>
class TestPlacement : public Placement<MO>
template<class DMO=DummyMO, class B=DummyMO>
class TestPlacement ;
template<>
class TestPlacement<> : public Placement<DummyMO>
{
public:
TestPlacement(DummyMO& testObject)
: Placement<MO>::Placement(testObject, &DummyMO::killDummy)
TestPlacement(DummyMO& dummyObj)
: Placement<DummyMO>::Placement(dummyObj, &DummyMO::killDummy)
{ }
};
template<class DMO, class B>
class TestPlacement : public TestPlacement<B>
{
public:
TestPlacement(DMO& dummyObj)
: TestPlacement<B>(dummyObj)
{ }
virtual DMO*
operator-> () const
{
ENSURE (INSTANCEOF (DMO, this->get()));
return static_cast<DMO*>
(Placement<MObject>::_SmartPtr::operator-> ());
}
};
template class TestPlacement<TestSubMO21,TestSubMO2>;
}} // namespace mobject::test

15
wiki/renderengine.html
View file

@ -2969,7 +2969,7 @@ We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes and T
&lt;&lt;tasksum end&gt;&gt;
</pre>
</div>
<div title="PlanningSessionInMem" modifier="Ichthyostega" modified="200904252308" created="200904252258" tags="impl SessionLogic draft" changecount="2">
<div title="PlanningSessionInMem" modifier="Ichthyostega" modified="200905291920" created="200904252258" tags="impl SessionLogic draft" changecount="16">
<pre>//This page is a scrapbook for working out the implementation of the [[Session Datastructure in Memory|SessionDataMem]]//
This is a difficult untertaking, because there are several dependencies (most of which aren't fully designed yet as of 5/09)
* the GUI uses an adapted version of the HighLevelModel; these datastructures are intended to be backed by the Session
@ -2980,7 +2980,7 @@ This is a difficult untertaking, because there are several dependencies (most of
!!!requirements
* can discover and ennumerate the structure
* can ennumerate the contents (objects) of a specific scope
* provide [[references|MObjectRef]] on these query/discovery operations
* provide [[references|MObjectRef]] as result of these query/discovery operations
!!!invariants
* memory management consistency
@ -2994,9 +2994,15 @@ This is a difficult untertaking, because there are several dependencies (most of
!Interface
&lt;&lt;task&gt;&gt;evaluate models for the [[reference problem|MObjectRef]]
&lt;&lt;task 2 3 3&gt;&gt; implement an hash-ID to be incorporated into placements
&lt;&lt;task 1 1 0&gt;&gt; implement PlacementRef
&lt;&lt;task 2 2 0&gt;&gt; implement MObjectRef
!Datastructure
&lt;&lt;task&gt;&gt;investigate the best granularity for object collections
&lt;&lt;task &gt;&gt; define a record to be used within the index
&lt;&lt;task &gt;&gt; implement basic index operations
&lt;&lt;task 1&gt;&gt; implement adding a placement relation
&lt;&lt;tasksum end&gt;&gt;
</pre>
@ -3090,7 +3096,7 @@ Besides, they provide an important __inward interface__ for the [[ProcNode]]s, w
</pre>
</div>
<div title="ProcLayer and Engine" modifier="Ichthyostega" modified="200812050522" created="200706190056" tags="overview" changecount="15">
<div title="ProcLayer and Engine" modifier="Ichthyostega" modified="200905291850" created="200706190056" tags="overview" changecount="18">
<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 [[the aspect of objects placed into the EDL|MObjects]] as well.
&lt;&lt;&lt;
''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a implementing the foundations and main structures in C++
@ -3099,12 +3105,13 @@ Besides, they provide an important __inward interface__ for the [[ProcNode]]s, w
* made a first draft of how to wire and operate procesing nodes (&amp;rarr;[[more|RenderMechanics]])
* working out the relation of [[Project, Timelines and Sequences|TimelineSequences]]
* first attempts to [[integrate with the GUI|GuiIntegration]]
* first outline of the [[session implementation|PlanningSessionInMem]]
&lt;&lt;&lt;
!Summary
We have several kinds of &quot;things&quot; organized as [[assets|Asset]] in the AssetManager, like media, clips, effects, codecs, configuration templates. Within the context of the [[EDL]], we can use these as [[&quot;Media Objects&quot;|MObjects]] &amp;mdash; especially, we can [[place|Placement]] them in various kinds within the EDL and relative to one another. Basically, this is the [[editing work|EditingOperations]] done by the user.
Now, from any given configuration within the EDL, we create sort or a frozen- and tied-down snapshot, here called [[&quot;Fixture&quot;|Fixture]], containing all currently active ~MObjects, broken down to elementary parts and made explicit if necessary. This Fixture acts as a isolation layer towards the Render Engine. We will hand it over to the [[Builder]], which in turn will transform it into a network of connected [[render nodes|ProcNode]]. This network //is// the [[Render Engine|OverviewRenderEngine]].
Now, from any given configuration within the EDL, we create sort or a frozen- and tied-down snapshot, here called [[&quot;Fixture&quot;|Fixture]], containing all currently active ~MObjects, broken down to elementary parts and made explicit if necessary. This Fixture acts as a isolation layer towards the Render Engine. We will hand it over to the [[Builder]], which in turn will transform it into a network of connected [[render nodes|ProcNode]]. This network //implements//&amp;nbsp; the [[Render Engine|OverviewRenderEngine]].
The system is ''open'' inasmuch every part mirrors the structure of corresponding parts in adjacent subsystems, and the transformation of any given structure from one subsystem (e.g. Asset) to another (e.g. Render Engine) is done with minimal &quot;magic&quot;. So the whole system should be able to handle completely new structures mostly by adding new configurations and components, without much need of rewriting basic workings.