diff --git a/.gitignore b/.gitignore index 5dc912d9e..10dbaee23 100644 --- a/.gitignore +++ b/.gitignore @@ -5,7 +5,7 @@ *.os *.gch ,valgrind.log* -Buildhelper.pyc +admin/scons/*.pyc optcache Makefile.in build/* diff --git a/SConstruct b/SConstruct index 066cd31b0..34d494b88 100644 --- a/SConstruct +++ b/SConstruct @@ -26,6 +26,8 @@ sys.path.append("./admin/scons") import os from Buildhelper import * +from LumieraEnvironment import * + #-----------------------------------Configuration OPTIONSCACHEFILE = 'optcache' @@ -33,6 +35,7 @@ CUSTOPTIONSFILE = 'custom-options' SRCDIR = 'src' BINDIR = 'bin' TESTDIR = 'tests' +ICONDIR = 'icons' VERSION = '0.1+pre.01' #-----------------------------------Configuration @@ -53,13 +56,13 @@ def setupBasicEnvironment(): EnsureSConsVersion(0,96,90) opts = defineCmdlineOptions() - - env = Environment(options=opts) - + env = LumieraEnvironment(options=opts) + env.Append ( CCCOM=' -std=gnu99') # workaround for a bug: CCCOM currently doesn't honor CFLAGS, only CCFLAGS env.Replace( VERSION=VERSION , SRCDIR=SRCDIR , BINDIR=BINDIR + , ICONDIR=ICONDIR , CPPPATH=["#"+SRCDIR] # used to find includes, "#" means always absolute to build-root , CPPDEFINES=['-DLUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines , CCFLAGS='-Wall ' # -fdiagnostics-show-option @@ -74,7 +77,7 @@ def setupBasicEnvironment(): appendVal(env,'ARCHFLAGS', 'CCFLAGS') # for both C and C++ appendVal(env,'OPTIMIZE', 'CCFLAGS', val=' -O3') appendVal(env,'DEBUG', 'CCFLAGS', val=' -ggdb') - + prepareOptionsHelp(opts,env) opts.Save(OPTIONSCACHEFILE, env) return env @@ -127,7 +130,7 @@ def defineCmdlineOptions(): ,PathOption('SRCTAR', 'Create source tarball prior to compiling', '..', PathOption.PathAccept) ,PathOption('DOCTAR', 'Create tarball with dev documentaionl', '..', PathOption.PathAccept) ) - + return opts @@ -161,38 +164,42 @@ def configurePlatform(env): setup platform specific options. Abort build in case of failure. """ - conf = Configure(env) - # run all configuration checks in the current env + conf = env.Configure() + # run all configuration checks in the given env + + # Perform checks for prerequisites -------------------------------------------- + if not conf.TryAction('pkg-config --version > $TARGET')[0]: + print 'We need pkg-config for including library configurations, exiting.' + Exit(1) - # Checks for prerequisites ------------ if not conf.CheckLibWithHeader('m', 'math.h','C'): print 'Did not find math.h / libm, exiting.' Exit(1) - + if not conf.CheckLibWithHeader('dl', 'dlfcn.h', 'C'): print 'Functions for runtime dynamic loading not available, exiting.' Exit(1) - + if not conf.CheckLibWithHeader('nobugmt', 'nobug.h', 'C'): print 'Did not find NoBug [http://www.pipapo.org/pipawiki/NoBug], exiting.' Exit(1) - + if not conf.CheckLibWithHeader('pthread', 'pthread.h', 'C'): print 'Did not find the pthread lib or pthread.h, exiting.' else: conf.env.Append(CPPFLAGS = ' -DHAVE_PTHREAD') conf.env.Append(CCFLAGS = ' -pthread') - + if conf.CheckCHeader('execinfo.h'): conf.env.Append(CPPFLAGS = ' -DHAS_EXECINFO_H') - + if conf.CheckCHeader('valgrind/valgrind.h'): conf.env.Append(CPPFLAGS = ' -DHAS_VALGRIND_VALGIND_H') if not conf.CheckCXXHeader('tr1/memory'): print 'We rely on the std::tr1 proposed standard extension for shared_ptr.' Exit(1) - + if not conf.CheckCXXHeader('boost/config.hpp'): print 'We need the C++ boost-lib.' Exit(1) @@ -206,8 +213,36 @@ def configurePlatform(env): if not conf.CheckLibWithHeader('boost_regex-mt','boost/regex.hpp','C++'): print 'We need the boost regular expression lib (incl. binary lib for linking).' Exit(1) - - + +# if not conf.CheckLibWithHeader('gavl', ['gavlconfig.h', 'gavl/gavl.h'], 'C'): + + if not conf.CheckPkgConfig('gavl', 1.0): + print 'Did not find Gmerlin Audio Video Lib [http://gmerlin.sourceforge.net/gavl.html], exiting.' + Exit(1) + else: + conf.env.mergeConf('gavl') + + if not conf.CheckPkgConfig('gtkmm-2.4', 2.8): + print 'Unable to configure GTK--, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('cairomm-1.0', 0.6): + print 'Unable to configure Cairo--, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('gdl-1.0', '0.6.1'): + print 'Unable to configure the GNOME DevTool Library, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('xv'): Exit(1) +# if not conf.CheckPkgConfig('xext'): Exit(1) +# if not conf.CheckPkgConfig('sm'): Exit(1) +# +# obviously not needed? + + print "** Gathered Library Info: %s" % conf.env.libInfo.keys() + + # create new env containing the finished configuration return conf.Finish() @@ -221,7 +256,7 @@ def definePackagingTargets(env, artifacts): artifacts['src.tar'] = t env.Alias('src.tar', t) env.Alias('tar', t) - + t = Tarball(env,location='$DOCTAR',suffix='-doc',dirs='admin doc wiki uml tests') artifacts['doc.tar'] = t env.Alias('doc.tar', t) @@ -240,7 +275,7 @@ def defineBuildTargets(env, artifacts): objlib = ( srcSubtree(env,'$SRCDIR/common') + srcSubtree(env,'$SRCDIR/lib') ) - plugobj = srcSubtree(env,'$SRCDIR/plugin', isShared=True) + objplug = srcSubtree(env,'$SRCDIR/plugin', isShared=True) core = ( env.StaticLibrary('$BINDIR/lumiback.la', objback) + env.StaticLibrary('$BINDIR/lumiproc.la', objproc) + env.StaticLibrary('$BINDIR/lumi.la', objlib) @@ -254,7 +289,7 @@ def defineBuildTargets(env, artifacts): env.Depends(objlib, precomp) artifacts['lumiera'] = env.Program('$BINDIR/lumiera', ['$SRCDIR/main.cpp']+ core ) - artifacts['plugins'] = env.SharedLibrary('$BINDIR/lumiera-plugin', plugobj) + artifacts['plugins'] = env.SharedLibrary('$BINDIR/lumiera-plugin', objplug) # call subdir SConscript(s) for independent components SConscript(dirs=[SRCDIR+'/tool'], exports='env artifacts core') @@ -276,7 +311,7 @@ def definePostBuildTargets(env, artifacts): # additional files to be cleaned when cleaning 'build' env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ]) env.Clean ('build', [ '$SRCDIR/pre.gch' ]) - + # Doxygen documentation # Note: at the moment we only depend on Doxyfile # obviousely, we should depend on all sourcefiles diff --git a/admin/scons/Buildhelper.py b/admin/scons/Buildhelper.py index ae3f5fb1f..02f17b2b4 100644 --- a/admin/scons/Buildhelper.py +++ b/admin/scons/Buildhelper.py @@ -90,6 +90,18 @@ def globRootdirs(roots): +def filterNodes(nlist, removeName=None): + """ filter out scons build nodes using the given criteria. + removeName: if set, remove all nodes with this srcname + """ + if removeName: + predicate = lambda n : not fnmatch.fnmatch(os.path.basename(str(n[0])), removeName) + else: + predicate = lambda n : True; + + return filter(predicate, nlist) + + def RegisterPrecompiledHeader_Builder(env): """ Registeres an Custom Builder for generating a precompiled Header. Note you should define a dependency to the PCH file @@ -111,7 +123,7 @@ def RegisterPrecompiledHeader_Builder(env): def Tarball(env,location,dirs,suffix=''): """ Custom Command: create Tarball of some subdirs - location: where to create the tar (optionally incl. filename.tar.gz) + location: where to create the tar (may optionally include filename.tar.gz) suffix: (optional) suffix to include in the tar name dirs: directories to include in the tar @@ -132,7 +144,7 @@ def Tarball(env,location,dirs,suffix=''): def createTarball(target,source,env): - """ helper, builds the tar using the python2.3 tarfil lib. + """ helper, builds the tar using the python2.3 tarfile lib. This allows us to prefix all paths, thus moving the tree into a virtual subdirectory containing the Version number, as needed by common packaging systems. diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py new file mode 100644 index 000000000..82d419a65 --- /dev/null +++ b/admin/scons/LumieraEnvironment.py @@ -0,0 +1,97 @@ +# -*- python -*- +## +## LumieraEnvironment.py - custom SCons Environment +## + +# Copyright (C) Lumiera.org +# 2008, Hermann Vosseler +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +##################################################################### + + +from SCons.SConf import SConf +from SCons.Environment import Environment + +from Buildhelper import * + + + +class LumieraEnvironment(Environment): + """ Custom SCons build environment for Lumiera + This allows us to carry structured config data without + using global vars. Idea inspired by Ardour. + """ + def __init__(self,*args,**kw): + Environment.__init__ (self,*args,**kw) + self.libInfo = {} + + def Configure (self, *args, **kw): + kw['env'] = self + return apply(LumieraConfigContext, args, kw) + + def mergeConf (self,other): + """ extract the library/compiler flags from other Environment. + Optionally accepts a list or just sting(s) representing keys + in our own libInfo Dictionary + """ + if isinstance(other, list): + for elm in other: + self.mergeConf(elm) + elif isinstance(other, str): + if other in self.libInfo: + self.mergeConf(self.libInfo[other]) + else: + self.Append (LIBS = other.get ('LIBS',[])) + self.Append (LIBPATH = other.get ('LIBPATH', [])) + self.Append (CPPPATH = other.get('CPPPATH', [])) + self.Append (LINKFLAGS = other.get('LINKFLAGS', [])) + + return self + + + def addLibInfo (self, libID, minVersion=0): + """ use pkg-config to create an Environment describing the lib. + Don't add this defs to the current Environment, rather store + them in the libInfo Dictionary. + """ + minVersion = str(minVersion) + if 0 != os.system('pkg-config --print-errors --exists "%s >= %s"' % (libID,minVersion)): + print "Problems configuring the Library %s (>= %s)" % (libID,minVersion) + return False + + self.libInfo[libID] = libInfo = LumieraEnvironment() + libInfo.ParseConfig ('pkg-config --cflags --libs '+ libID ) + return libInfo + + def Glob (self, pattern): + """ temporary workaround; newer versions of SCons provide this as a global function + """ + pattern = self.subst(pattern) + return glob.glob(pattern) + + +class LumieraConfigContext(SConf): + """ Extends the SCons Configure context with some convenience methods + """ + def __init__(self, *args,**kw): + SConf.__init__(self,*args,**kw) + + def CheckPkgConfig (self, libID, minVersion=0): + print "Checking for library configuration: %s " % libID + # self.Message(self,"Checking for library configuration: %s " % libID) + return self.env.addLibInfo (libID, minVersion) + + diff --git a/doc/devel/uml/class130949.html b/doc/devel/uml/class130949.html index 774585ac5..05f451c34 100644 --- a/doc/devel/uml/class130949.html +++ b/doc/devel/uml/class130949.html @@ -18,7 +18,7 @@

Declaration :

Encapsulates the logic used to get a "current render process" in accordance to the currentyl applicable controller settings. The provided StateProxy serves to hold any mutalbe state used in the render process, so the rest of the render engine can be stateless.

Artifact : renderstate

-
Operation getStateProxy

Declaration :

+
Operation getStateProxy

Declaration :

All public operations : getStateProxy

diff --git a/doc/devel/uml/class131589.html b/doc/devel/uml/class131589.html index c65bef7fb..86ae3636b 100644 --- a/doc/devel/uml/class131589.html +++ b/doc/devel/uml/class131589.html @@ -18,5 +18,6 @@

Declaration :

The output of the render pipeline. Pulling from such exit nodes actually ivokes the render process

Artifact : exitnode

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131717.html b/doc/devel/uml/class131717.html index d03898369..2a2783381 100644 --- a/doc/devel/uml/class131717.html +++ b/doc/devel/uml/class131717.html @@ -16,10 +16,14 @@ -

Declaration :

Directly inherited by : ExitNode Hub Link Source Trafo

+

Declaration :

Directly inherited by : ExitNode Link Source Trafo

Key abstraction of the Render Engine: A Data processing Node

Artifact : procnode

Relation datasrc (<unidirectional association>)

Declaration :

The predecessor in a processing pipeline, i.e. a source to get data to be processed

-
Relation params (<directional aggregation by value>)

Declaration :

+
Relation params (<directional aggregation by value>)

Declaration :

+
Relation predecessors (<directional aggregation by value>)

Declaration :

+
Operation pull

Declaration :

+
Operation process

Declaration :

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131845.html b/doc/devel/uml/class131845.html index 278d1cdb1..1a439ca08 100644 --- a/doc/devel/uml/class131845.html +++ b/doc/devel/uml/class131845.html @@ -19,5 +19,6 @@

Declaration :

Directly inherited by : CodecAdapter Mask PluginAdapter Projector

Artifact : trafo

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131973.html b/doc/devel/uml/class131973.html index 68e7e24de..5e99f1b3d 100644 --- a/doc/devel/uml/class131973.html +++ b/doc/devel/uml/class131973.html @@ -16,8 +16,8 @@ -

Declaration :

Directly inherited by : GLPipe

-

Artifact : link

+

Declaration :

Artifact : link

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132229.html b/doc/devel/uml/class132229.html index f0ba8e9d7..8fc999275 100644 --- a/doc/devel/uml/class132229.html +++ b/doc/devel/uml/class132229.html @@ -18,5 +18,6 @@

Declaration :

Special video processing node used to scale and translate image data.

Artifact : projector

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132357.html b/doc/devel/uml/class132357.html index 0d94f52bc..1b054fe8f 100644 --- a/doc/devel/uml/class132357.html +++ b/doc/devel/uml/class132357.html @@ -18,5 +18,6 @@

Declaration :

Artifact : mask

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132485.html b/doc/devel/uml/class132485.html index b6389bd12..54bafe5c9 100644 --- a/doc/devel/uml/class132485.html +++ b/doc/devel/uml/class132485.html @@ -18,5 +18,6 @@

Declaration :

Adapter used to integrage an effects processor in the render pipeline

Artifact : pluginadapter

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132741.html b/doc/devel/uml/class132741.html index f0a749926..89bb5e220 100644 --- a/doc/devel/uml/class132741.html +++ b/doc/devel/uml/class132741.html @@ -4,21 +4,26 @@ -Class StateProxy +Class State -
Class StateProxy
+
Class State

-

Declaration :

Directly inherited by : ARender GLRender VRender

+

Declaration :

Directly inherited by : StateAdapter StateProxy

Artifact : stateproxy, Component(s) : Builder

-
Relation currFrame (<unidirectional association>)

Declaration :

  • Uml : # currFrame : Frame
  • C++ : protected: Frame * currFrame
+
Relation currFrame (<unidirectional association>)

Declaration :

+
Operation fetch

Declaration :

+
Operation allocateBuffer

Declaration :

+
Operation releaseBuffer

Declaration :

+
Operation isCalculated

Declaration :

+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

diff --git a/doc/devel/uml/class132997.html b/doc/devel/uml/class132997.html deleted file mode 100644 index 7680639be..000000000 --- a/doc/devel/uml/class132997.html +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - -Class VRender - - - - - -
Class VRender
-

- - - - -

Declaration :

Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)

Artifact : vrender

-
- - diff --git a/doc/devel/uml/class133765.html b/doc/devel/uml/class133765.html index af0e6bfb1..b6f9bde2d 100644 --- a/doc/devel/uml/class133765.html +++ b/doc/devel/uml/class133765.html @@ -18,5 +18,6 @@

Declaration :

Source Node: represents a media source to pull data from.

Artifact : source

+

All public operations : process , pull

diff --git a/doc/devel/uml/class135045.html b/doc/devel/uml/class135045.html index 16259137b..c91ed83fb 100644 --- a/doc/devel/uml/class135045.html +++ b/doc/devel/uml/class135045.html @@ -18,5 +18,6 @@

Declaration :

Artifact : codecadapter

+

All public operations : process , pull

diff --git a/doc/devel/uml/class142469.html b/doc/devel/uml/class142469.html new file mode 100644 index 000000000..58c82f008 --- /dev/null +++ b/doc/devel/uml/class142469.html @@ -0,0 +1,23 @@ + + + + + + +Class StateProxy + + + + + +
Class StateProxy
+

+ + + + +

Declaration :

+
+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class142597.html b/doc/devel/uml/class142597.html new file mode 100644 index 000000000..69ed2147c --- /dev/null +++ b/doc/devel/uml/class142597.html @@ -0,0 +1,26 @@ + + + + + + +Class StateAdapter + + + + + +
Class StateAdapter
+

+ + + + +

Declaration :

+ +
Operation retrieve

Declaration :

+
Relation state (<unidirectional association>)

Declaration :

+
Relation <unidirectional association>

Declaration :

+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer , retrieve

+ + diff --git a/doc/devel/uml/class142725.html b/doc/devel/uml/class142725.html new file mode 100644 index 000000000..93345b68f --- /dev/null +++ b/doc/devel/uml/class142725.html @@ -0,0 +1,25 @@ + + + + + + +Class WiringDescriptor + + + + + +
Class WiringDescriptor
+

+ + + + +

Declaration :

Directly inherited by : NodeWiring

+
+ +
Operation callDown

Declaration :

+

All public operations : callDown

+ + diff --git a/doc/devel/uml/class132101.html b/doc/devel/uml/class143109.html similarity index 60% rename from doc/devel/uml/class132101.html rename to doc/devel/uml/class143109.html index ca7d5ac7e..f2696562b 100644 --- a/doc/devel/uml/class132101.html +++ b/doc/devel/uml/class143109.html @@ -4,19 +4,17 @@ -Class Hub +Class BackendCache -
Class Hub
+
Class BackendCache

- -

Declaration :

Artifact : hub

-
- + +

Declaration :

diff --git a/doc/devel/uml/class143237.html b/doc/devel/uml/class143237.html new file mode 100644 index 000000000..b1b5a8387 --- /dev/null +++ b/doc/devel/uml/class143237.html @@ -0,0 +1,20 @@ + + + + + + +Class Caller + + + + + +
Class Caller
+

+ + + + +

Declaration :

+ diff --git a/doc/devel/uml/class143365.html b/doc/devel/uml/class143365.html new file mode 100644 index 000000000..c4e3718c3 --- /dev/null +++ b/doc/devel/uml/class143365.html @@ -0,0 +1,28 @@ + + + + + + +Class NodeWiring + + + + + +
Class NodeWiring
+

+ + + + +

Declaration :

+ +
Relation <association>

Declaration :

+
Relation <association>

Declaration :

+
Relation <association>

Declaration :

+
Relation <unidirectional association>

Declaration :

+
Operation callDown

Declaration :

+

All public operations : callDown , callDown

+ + diff --git a/doc/devel/uml/class143493.html b/doc/devel/uml/class143493.html new file mode 100644 index 000000000..37a6496d9 --- /dev/null +++ b/doc/devel/uml/class143493.html @@ -0,0 +1,21 @@ + + + + + + +Class OperationBase + + + + + +
Class OperationBase
+

+ + + + +

Declaration :

Directly inherited by : FeedCache ProcessData ReadSource

+ + diff --git a/doc/devel/uml/class132869.html b/doc/devel/uml/class143621.html similarity index 56% rename from doc/devel/uml/class132869.html rename to doc/devel/uml/class143621.html index 743378103..649d441e7 100644 --- a/doc/devel/uml/class132869.html +++ b/doc/devel/uml/class143621.html @@ -4,19 +4,20 @@ -Class ARender +Class QueryCache -
Class ARender
+
Class QueryCache

- -

Declaration :

Representation of a Audio render process

Artifact : arender

+ +

Declaration :

Directly inherited by : Strategy

+
diff --git a/doc/devel/uml/class143749.html b/doc/devel/uml/class143749.html new file mode 100644 index 000000000..426d12aaa --- /dev/null +++ b/doc/devel/uml/class143749.html @@ -0,0 +1,24 @@ + + + + + + +Class PullInput + + + + + +
Class PullInput
+

+ + + + +

Declaration :

Directly inherited by : QueryCache Strategy

+
+ +
Relation <association>

Declaration :

+ + diff --git a/doc/devel/uml/class133125.html b/doc/devel/uml/class143877.html similarity index 55% rename from doc/devel/uml/class133125.html rename to doc/devel/uml/class143877.html index 140cc4b67..bad34df65 100644 --- a/doc/devel/uml/class133125.html +++ b/doc/devel/uml/class143877.html @@ -4,19 +4,20 @@ -Class GLRender +Class ReadSource -
Class GLRender
+
Class ReadSource

- -

Declaration :

Representation of a OpenGL accelerated Video render process

Artifact : glrender

+ +

Declaration :

Directly inherited by : Strategy

+
diff --git a/doc/devel/uml/class144005.html b/doc/devel/uml/class144005.html new file mode 100644 index 000000000..bc2bf60f2 --- /dev/null +++ b/doc/devel/uml/class144005.html @@ -0,0 +1,24 @@ + + + + + + +Class BuffTable + + + + + +
Class BuffTable
+

+ + + + +

Declaration :

  • C++ : template<int SIZ> class BuffTable
+ +
Relation <directional aggregation by value>

Declaration :

+
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class144133.html b/doc/devel/uml/class144133.html new file mode 100644 index 000000000..995d09019 --- /dev/null +++ b/doc/devel/uml/class144133.html @@ -0,0 +1,20 @@ + + + + + + +Class BuffHandle + + + + + +
Class BuffHandle
+

+ + + + +

Declaration :

  • C++ : class BuffHandle
+ diff --git a/doc/devel/uml/class144261.html b/doc/devel/uml/class144261.html new file mode 100644 index 000000000..d9c258fab --- /dev/null +++ b/doc/devel/uml/class144261.html @@ -0,0 +1,25 @@ + + + + + + +Class Invocation + + + + + +
Class Invocation
+

+ + + + +

Declaration :

  • C++ : class Invocation
+ +
Relation <unidirectional association>

Declaration :

+
Relation <unidirectional association>

Declaration :

+
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class144389.html b/doc/devel/uml/class144389.html new file mode 100644 index 000000000..fb3f25daf --- /dev/null +++ b/doc/devel/uml/class144389.html @@ -0,0 +1,24 @@ + + + + + + +Class ProcessData + + + + + +
Class ProcessData
+

+ + + + +

Declaration :

Directly inherited by : PullInput

+
+ +
Relation <association>

Declaration :

+ + diff --git a/doc/devel/uml/class144517.html b/doc/devel/uml/class144517.html new file mode 100644 index 000000000..8eace63da --- /dev/null +++ b/doc/devel/uml/class144517.html @@ -0,0 +1,25 @@ + + + + + + +Class Strategy + + + + + +
Class Strategy
+

+ + + + +

Declaration :

+ +
Relation <association>

Declaration :

+
Relation <association>

Declaration :

+
Relation <association>

Declaration :

+ + diff --git a/doc/devel/uml/class132613.html b/doc/devel/uml/class144645.html similarity index 53% rename from doc/devel/uml/class132613.html rename to doc/devel/uml/class144645.html index 0134205d1..c5cc7c0cb 100644 --- a/doc/devel/uml/class132613.html +++ b/doc/devel/uml/class144645.html @@ -4,19 +4,20 @@ -Class GLPipe +Class FeedCache -
Class GLPipe
+
Class FeedCache

- -

Declaration :

  • C++ : class GLPipe : public Link

specialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form

Artifact : glpipe

+ +

Declaration :

Directly inherited by : ProcessData

+
diff --git a/doc/devel/uml/classdiagrams.html b/doc/devel/uml/classdiagrams.html index 4cf5416cc..e1289d57d 100644 --- a/doc/devel/uml/classdiagrams.html +++ b/doc/devel/uml/classdiagrams.html @@ -27,8 +27,10 @@ Media-Asset Relations Proc-Asset Relations Render Entities +Render Mechanics Rules access Session structure +StateAdapter composition Struct-Asset Relations diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 23162b8f6..319577971 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -21,15 +21,18 @@ Allocationa directive to place a MObject in a specific way AppconfigsingletonSingleton to hold inevitable global flags and constants and for performing erarly (static) global initialization tasks. Applicable -ARenderRepresentation of a Audio render process AssemblerThis is the actual building facility: provided the correct tools and associations, it serves to build and connect the individual ProcNode objects AssetinterfaceSuperinterface describing especially the bookeeping properties of Assets AssetManagerboundaryFacade for the Asset subsystem AutoAutomation data for some parameter (i.e. a time varying function) +BackendCache +BuffHandle +BuffTable Buildableinterface BuilderFacadeboundaryProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade BuilderToolinterfaceUsed according to the visitor pattern: each Tool contains the concrete implementation for one task to be done to the various MObject classes BuildInstruct(Interface) building instructions to be executed by the Builder on the render node network under construction. +Caller Categorytree like classification of Assets Clipbookkeeping (asset) view of a media clip. Clip @@ -57,6 +60,7 @@ ExplicitPlacementinterface External Factorya template for generating functor-like Factory objects, used to encapsulate object creation and providing access via smart-pointers only. +FeedCache File FileHandle FileHandleCache @@ -71,11 +75,9 @@ FrameDescriptorinterfaceA FrameDescriptor implements the higher level interfaces for frames. Further refinements are made by subclassing and policy classes FrameReference GLBuf -GLPipespecialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form -GLRenderRepresentation of a OpenGL accelerated Video render process -Hub InterpolatorProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter Invalid +Invocation Label Link LocatingPinAn element with value semantics, which actually implements the placement of some MObject by positioning it in some way. @@ -91,6 +93,8 @@ MObjectinterface MutexI provided a reworked Mutex class in my Cinelerra2 repository NodeCreatorToolThis Tool implementation plays the central role in the buld process: given a MObject from Session, it is able to attach ProcNodes to the render engine under construction such as to reflect the properties of the MObject in the actual render. +NodeWiring +OperationBase ParameterDescriptor and access object for a plugin parameter. Parameters may be provided with values from the session, and this values may be automated. ParamProviderinterfaceA facility to get the actual value of a plugin/effect parameter PathManagerWhile building a render engine, this Strategy class decides on the actual render strategy in accordance to the current controller settings (system state) @@ -101,12 +105,17 @@ Prefetch Previewalternative version of the media data, probably with lower resolution Prockey abstraction: data processing asset +ProcDispatcher +ProcessData Processor ProcNodeinterfaceKey abstraction of the Render Engine: A Data processing Node ProcPattspecial type of structural Asset representing information how to build some part of the render engine's processing nodes network. ProjectorSpecial video processing node used to scale and translate image data. +PullInput +QueryCache QueryHandlerinterface QueryHandlerImpl +ReadSource RelativeLocation RelTypeenumthe possible kinds of RelativePlacements RenderEngine @@ -122,9 +131,12 @@ SimpleClipElementary clip consisting of only one media stream SmartPointerauxiliary SourceSource Node: represents a media source to pull data from. +Stateinterface State -StateProxyinterface +StateAdapter +StateProxyimplementation std::exceptionauxiliary +Strategy Structkey abstraction: structural asset ThreadWe can basically reuse the Thread class design from Cinelerra2, Thread becomes a baseclass for all Threads Timedenotes a temporal position (time point), based on timeline start.

investigate posix.4 realtime timers, wrap these here @@ -139,7 +151,7 @@ Useractor VFrame Visitable -VRenderRepresentation of a Video render process. (Encapsulates the video buffers for the actual calculations) +WiringDescriptor Wish WriteBuffer WriteBufferPool diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 6f3005da9..8e8c2d9a6 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -22,15 +22,18 @@ Allocation
Appconfig
Applicable
-ARender
Assembler
Asset
AssetManager
Auto
+BackendCache
+BuffHandle
+BuffTable
Buildable
BuilderFacade
BuilderTool
BuildInstruct
+Caller
Category
Clip
Clip
@@ -58,6 +61,7 @@ ExplicitPlacement
External
Factory
+FeedCache
File
FileHandle
FileHandleCache
@@ -72,11 +76,9 @@ FrameDescriptor
FrameReference
GLBuf
-GLPipe
-GLRender
-Hub
Interpolator
Invalid
+Invocation
Label
Link
LocatingPin
@@ -92,6 +94,8 @@ MObject
Mutex
NodeCreatorTool
+NodeWiring
+OperationBase
Parameter
ParamProvider
PathManager
@@ -102,12 +106,17 @@ Prefetch
Preview
Proc
+ProcDispatcher
+ProcessData
Processor
ProcNode
ProcPatt
Projector
+PullInput
+QueryCache
QueryHandler
QueryHandlerImpl
+ReadSource
RelativeLocation
RelType
RenderEngine
@@ -123,9 +132,12 @@ SimpleClip
SmartPointer
Source
+State
State
-StateProxy
+StateAdapter
+StateProxy
std::exception
+Strategy
Struct
Thread
Time
@@ -140,7 +152,7 @@ User
VFrame
Visitable
-VRender
+WiringDescriptor
Wish
WriteBuffer
WriteBufferPool
diff --git a/doc/devel/uml/collaborationdiagrams.html b/doc/devel/uml/collaborationdiagrams.html index 2d8ab627d..5ccf1d4a5 100644 --- a/doc/devel/uml/collaborationdiagrams.html +++ b/doc/devel/uml/collaborationdiagrams.html @@ -18,6 +18,7 @@ +
"default" object
build processThis figure shows the process of building and starting a RenderEngine
Render Process
diff --git a/doc/devel/uml/fig128005.png b/doc/devel/uml/fig128005.png index e9bef7624..4cae19a1d 100644 Binary files a/doc/devel/uml/fig128005.png and b/doc/devel/uml/fig128005.png differ diff --git a/doc/devel/uml/fig128389.png b/doc/devel/uml/fig128389.png index c6a57b857..fa8dcdc95 100644 Binary files a/doc/devel/uml/fig128389.png and b/doc/devel/uml/fig128389.png differ diff --git a/doc/devel/uml/fig128901.png b/doc/devel/uml/fig128901.png index 6bb94e8cc..bd2b52fe1 100644 Binary files a/doc/devel/uml/fig128901.png and b/doc/devel/uml/fig128901.png differ diff --git a/doc/devel/uml/fig129029.png b/doc/devel/uml/fig129029.png index 6313cb7fb..3e8223916 100644 Binary files a/doc/devel/uml/fig129029.png and b/doc/devel/uml/fig129029.png differ diff --git a/doc/devel/uml/fig129157.png b/doc/devel/uml/fig129157.png index 4629abad9..7ce020fc6 100644 Binary files a/doc/devel/uml/fig129157.png and b/doc/devel/uml/fig129157.png differ diff --git a/doc/devel/uml/fig129285.png b/doc/devel/uml/fig129285.png index d8f8bec2e..c42d770d3 100644 Binary files a/doc/devel/uml/fig129285.png and b/doc/devel/uml/fig129285.png differ diff --git a/doc/devel/uml/fig130053.png b/doc/devel/uml/fig130053.png index 9cee6c87a..c25a4871d 100644 Binary files a/doc/devel/uml/fig130053.png and b/doc/devel/uml/fig130053.png differ diff --git a/doc/devel/uml/fig130821.png b/doc/devel/uml/fig130821.png index 8f9dab369..0c951bf06 100644 Binary files a/doc/devel/uml/fig130821.png and b/doc/devel/uml/fig130821.png differ diff --git a/doc/devel/uml/fig131973.png b/doc/devel/uml/fig131973.png new file mode 100644 index 000000000..d16d88131 Binary files /dev/null and b/doc/devel/uml/fig131973.png differ diff --git a/doc/devel/uml/fig132229.png b/doc/devel/uml/fig132229.png new file mode 100644 index 000000000..4cc4b71d5 Binary files /dev/null and b/doc/devel/uml/fig132229.png differ diff --git a/doc/devel/uml/fig132357.png b/doc/devel/uml/fig132357.png new file mode 100644 index 000000000..8f89db240 Binary files /dev/null and b/doc/devel/uml/fig132357.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index bbecbcbc0..1081df7d3 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -32,7 +32,7 @@ Documentation

provided classes : Error, Time

Component Builder
-

provided classes : StateProxy

+

provided classes : State

required classes : Fixture, SessionImpl

Component Session
@@ -54,9 +54,10 @@ Documentation
Component AssetManagement
Component Dispatcher
+

provided classes : ProcDispatcher

Component Engine
-

Depends on Frame (Stream) Provider

required classes : StateProxy

+

Depends on Frame (Stream) Provider

required classes : State

Component ProcNode
@@ -78,6 +79,9 @@ Documentation

required classes : MediaAccessFacade

Component AssetDB
+ +
Component client code
+

required classes : ProcDispatcher

1.2 Component View interfaces

@@ -112,7 +116,7 @@ Documentation
Artifact Lumiera

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool

+

executable associated with : glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label

Artifact main

Artifact source

@@ -192,7 +196,7 @@ Documentation
Artifact stateproxy

Key Interface representing a render process and encapsulating state

-

Artifact source associated with : StateProxy

+

Artifact source associated with : State

Artifact controllerfacade

Facade and service access point for the Proc Layer Controller

@@ -517,7 +521,7 @@ Documentation
Artifact hub

special ProcNode used to build data distributing connections

-

Artifact source associated with : Hub

+

Artifact source

Artifact projector

video ProcNode for scaling and translating image data

@@ -537,19 +541,19 @@ Documentation
Artifact glpipe

specialized connection element for handling OpenGL implementation details

-

Artifact source associated with : GLPipe

+

Artifact source

Artifact arender

Representation of a Audio Render process

-

Artifact source associated with : ARender

+

Artifact source

Artifact vrender

Representation of a Video render process

-

Artifact source associated with : VRender

+

Artifact source

Artifact glrender

Representation of a OpenGL accellerated Video render process

-

Artifact source associated with : GLRender

+

Artifact source

Artifact aframe

a buffer and render process holding a Audio frame

@@ -670,6 +674,7 @@ Documentation
Class ParamProvider
Class Interpolator
Class LocatingPin
+
Class ProcDispatcher

2.2.2 Package Builder

@@ -759,7 +764,7 @@ Documentation
Class ToolFactory
Class ConManager
Class Assembler
-
Class StateProxy
+
Class State
Class Buildable
Class BuilderTool
Class SegmentationTool
@@ -872,26 +877,41 @@ reuse exiting Engine

Selection :

    Transformation

    Automation Entities



    + +

    +

    Render Mechanics



    + +

    +

    StateAdapter composition



    Class RenderEngine
    Class Processor
    Class ExitNode
    Class ProcNode
    Class Trafo
    Class Link
    -
    Class Hub
    Class Projector
    Class Mask
    Class PluginAdapter
    Class CodecAdapter
    -
    Class GLPipe
    -
    Class ARender
    -
    Class VRender
    -
    Class GLRender
    Class Frame
    Class AFrame
    Class VFrame
    Class GLBuf
    Class Source
    +
    Class StateProxy
    +
    Class StateAdapter
    +
    Class WiringDescriptor
    +
    Class NodeWiring
    +
    Class OperationBase
    +
    Class QueryCache
    +
    Class PullInput
    +
    Class ReadSource
    +
    Class ProcessData
    +
    Class FeedCache
    +
    Class Strategy
    +
    Class BuffTable
    +
    Class BuffHandle
    +
    Class Invocation
    @@ -1005,13 +1025,7 @@ reuse exiting Engine

    Selection :

    Transformation

  • datasrc = input

    • Class instance vid_a

    type :Source

    -
    Class instance aud_a

    type :Source

    -
    Class instance vid1

    type :VRender

    relations :

    -
    Class instance au1

    type :ARender

    relations :

    +
    Class instance aud_a

    type :Source

    Class instance

    type :VFrame

    Class instance

    type :AFrame

    Class instance

    type :RenderEngine

    relations :

    Selection :

    Transformation

    Class instance HUE

    type :PluginAdapter

    relations :

    -
    Class instance vid1

    type :VRender

    relations :

    Class instance

    type :VFrame

    Class instance video1

    type :Processor

    attributes :

    Selection :

    Transformation

    Class instance video

    type :ExitNode

    relations :

    +

    +

    +

    Render Process



    + +
    Class instance node1

    type :ProcNode

    +
    Class instance ad1

    type :StateAdapter

    +
    Class instance current

    type :StateProxy

    +
    Class instance node2

    type :ProcNode

    +
    Class instance ad2

    type :StateAdapter

    Class BackendCache
    +
    Class Caller
    + +
    Class instance node3

    type :ProcNode

    +
    Class instance ad3

    type :StateAdapter

    +
    Class instance vid1

    type :StateProxy

    +
    Class instance au1

    type :StateProxy

    3 Package BackendLayer

    diff --git a/doc/devel/uml/index_60.html b/doc/devel/uml/index_60.html index 4909e634c..a873c25b0 100644 --- a/doc/devel/uml/index_60.html +++ b/doc/devel/uml/index_60.html @@ -30,8 +30,8 @@ <flow>transition <flow>transition <flow>transition -<flow>transition <flow>transition +<flow>transition <flow>transition <flow>transition <flow>transition diff --git a/doc/devel/uml/index_65.html b/doc/devel/uml/index_65.html index 3fce72879..33d5ebd2f 100644 --- a/doc/devel/uml/index_65.html +++ b/doc/devel/uml/index_65.html @@ -23,9 +23,13 @@ access Fileuse case activity finalactivity final activity finalactivity final +ad1class instance +ad2class instance +ad3class instance add new object to sessionuse case AFrameclass aframeartifacta buffer and render process holding a Audio frame +allocateBufferoperation allocationartifact Allocationclassa directive to place a MObject in a specific way anchorrelation @@ -36,7 +40,6 @@ applyoperation applyoperation Architecturecomponent viewThe various Components comprising the Lumiera Video editing Application -ARenderclassRepresentation of a Audio render process arenderartifactRepresentation of a Audio Render process AssemblerclassThis is the actual building facility: provided the correct tools and associations, it serves to build and connect the individual ProcNode objects assemblerartifactbuilding facility (implementation of the build process) @@ -51,13 +54,13 @@ assetmanagerartifactFacade for the Asset subsystem Assetsclass view ATTACHattributeattach subject to anchor (e.g. an effect to a clip) -au1class instance +au1class instance aud_Aclass instance aud_aclass instance audioclass instance -audio1class instance -audio1class instance audio1class instance +audio1class instance +audio1class instance autoartifactMedia Object holding automation data AutoclassAutomation data for some parameter (i.e. a time varying function) Automation Entitiesclass diagram diff --git a/doc/devel/uml/index_66.html b/doc/devel/uml/index_66.html index 2d9540c91..3a6ba7379 100644 --- a/doc/devel/uml/index_66.html +++ b/doc/devel/uml/index_66.html @@ -21,7 +21,10 @@ Backend Componentsclass view backend use casesuse case diagram backend-componentscomponent diagram +BackendCacheclass BackendLayerpackage +BuffHandleclass +BuffTableclass buildoperation build flowactivity diagram build necessary?decision activity node diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index 08c04b765..8432e5cc6 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -19,46 +19,50 @@ NameKindDescription Cachecomponent Cachecomponent view +callDownoperation +callDownoperation +Callerclass categoryrelationprimary tree like classification of the asset Categoryclasstree like classification of Assets categoryartifacttree like classification of Assets causeattributea copy of the first exception encountered in this exception chain -chainrelationChain of additional Placements further constraining the position of this MObject chainoperationcreate and add another Placement for this media object, thus increasingly constraining the (possible) position of this object. +chainrelationChain of additional Placements further constraining the position of this MObject checked_inrelationchecked_in objects are subject of cache aging and must be not in use checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging +class instanceclass instance +class instanceclass instance +class instanceclass instance class instanceclass instance +class instanceclass instance class instanceclass instance class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance clearoperationclear current session contents
    without resetting overall session config.
    Afterwards, the session will contain only one
    empty EDL, while all Assets are retained.
    +client codecomponent Clipclassbookkeeping (asset) view of a media clip. -clipartifactbookkeeping (asset) view of a media clip. clipartifacta Media Clip +clipartifactbookkeeping (asset) view of a media clip. Clipclass clipsrelation Codecclassdescription of some media data decoder or encoder facility @@ -104,6 +108,7 @@ create specific objectuse case createClipoperationcreate a (possibly compound) Clip refering to this media, ready to be added to the EDL. currEDLoperationThe EDL currently in focus. In most cases, Session and EDL are almost the same, just EDL emphasizes the collection aspect. But generally (for larger editing projects) one Session can contain several EDLs, which may even be nested. At any given time, only one of these EDLs has focus and recieves the editing commands. +currentclass instance currentrelationStandard access path to get at the current session via the Session Manager, which acts as a "PImpl" smart pointer currFramerelation diff --git a/doc/devel/uml/index_68.html b/doc/devel/uml/index_68.html index 90bc7ba4d..e9e768a1e 100644 --- a/doc/devel/uml/index_68.html +++ b/doc/devel/uml/index_68.html @@ -32,8 +32,8 @@ designpackage designpackageAll things concering the big picture.
    Not a real code package, rather a container for design drafts, specifications, decisions. detect Channelsuse case -determine Render Paramsexpansion region determine Render Paramsopaque activity action +determine Render Paramsexpansion region devnullclass instance Dispatchercomponent dispatchOpoperation diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index 6c17d406d..a7245b34b 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -18,8 +18,8 @@ - + diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index 78b986b1b..56bc1daaf 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -18,6 +18,8 @@
    NameKindDescription
    edlartifactthe (high level) Edit Decision List within the current Session
    EDLclass
    EDLcomponent
    EDLclass
    EDL Example1object diagramA simple example showing how the actual objects are placed in the Fixture (=definitive playlist). It shows a Video and Audio clip placed on two tracks
    EDL Example2object diagramMore complex example showing the Object graph in the EDL and how it is linked into the Fixture to yield the actual locations. In this example, an HUE Effect is applied on a part of the Clip
    edlsrelation
    + + diff --git a/doc/devel/uml/index_71.html b/doc/devel/uml/index_71.html index 82430e314..f4ad7d96d 100644 --- a/doc/devel/uml/index_71.html +++ b/doc/devel/uml/index_71.html @@ -46,9 +46,7 @@ - - diff --git a/doc/devel/uml/index_72.html b/doc/devel/uml/index_72.html index 0abaaac68..7e5b73a00 100644 --- a/doc/devel/uml/index_72.html +++ b/doc/devel/uml/index_72.html @@ -22,10 +22,9 @@ - - +
    NameKindDescription
    Factoryclassa template for generating functor-like Factory objects, used to encapsulate object creation and providing access via smart-pointers only.
    FeedCacheclass
    fetchoperation
    Fileclass
    filerelation
    File Mappingclass diagramShows whats used to access Frames
    getValueoperation
    GLBufclass
    glbufartifacta buffer and render process holding a Video frame for OpenGL rendering
    GLPipeclassspecialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form
    glpipeartifactspecialized connection element for handling OpenGL implementation details
    GLRenderclassRepresentation of a OpenGL accelerated Video render process
    glrenderartifactRepresentation of a OpenGL accellerated Video render process
    groupsattributeadditional classification, selections or departments this asset belongs to. Groups are optional, non-exclusive and may be overlapping.
    guipackagesourcecode package

    User Interface classes go here
    handles_availableattributeinitialized to the maximum number of filehandles the backend may use for mapped files. When no handles are available, the handle which is last in the handles list is closed and (re-)used.
    Else this number is decremented for each new filehandle used and incremented for any one explicitly freed.
    Hierarchyclass diagramLumiera Exception hierarchy
    howtoProcoperation@return descriptor how to build a render pipeline corresponding to this media
    Hubclass
    hubartifactspecial ProcNode used to build data distributing connections
    HUEclass instance
    HUEclass instance
    HUEclass instance
    diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 798945020..e127cf07e 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -21,8 +21,8 @@ In Memory Databaseclass diagram inFixtureactivity action pin inputclass instance -inputclass instance inputclass instance +inputclass instance instanceoperation instructionsrelation Interfaceclass view @@ -31,8 +31,10 @@ interpolatorartifactdenotes a facility to get (continuously interpolated) parameter values InterpolatorclassProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter Invalidclass +Invocationclass iporelation isActiveoperationweather this asset is swithced on and consequently included in the fixture and participates in rendering +isCalculatedoperation diff --git a/doc/devel/uml/index_78.html b/doc/devel/uml/index_78.html index 1cf51971d..74fa8a9d8 100644 --- a/doc/devel/uml/index_78.html +++ b/doc/devel/uml/index_78.html @@ -20,9 +20,13 @@ nameattributeelement ID, comprehensible but sanitized. The tuple (category, name, org) is unique. need sub objectuse case nextrelationnext additional LocatingPin, if any +node1class instance +node2class instance +node3class instance nodecreatertoolartifactcentral Tool implementing the Renderengine building NodeCreatorToolclassThis Tool implementation plays the central role in the buld process: given a MObject from Session, it is able to attach ProcNodes to the render engine under construction such as to reflect the properties of the MObject in the actual render. nodesrelation +NodeWiringclass diff --git a/doc/devel/uml/index_79.html b/doc/devel/uml/index_79.html index 4ac4c3b33..e17eadde8 100644 --- a/doc/devel/uml/index_79.html +++ b/doc/devel/uml/index_79.html @@ -18,10 +18,11 @@ + + - diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index ba34ae763..368babe6a 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -40,6 +40,7 @@ + @@ -51,6 +52,9 @@ + + + @@ -62,6 +66,8 @@ + +
    NameKindDescription
    offsetattributeOffset the actual position by this (time) value relative to the anchor point. TODO: Representation?
    OperationBaseclass
    orgattributeorigin or authorship id. Can be a project abbreviation, a package id or just the authors nickname or UID. This allows for the compnent name to be more generic (e.g. "blur"). Default for all assets provided by the core Lumiera codebase is "lumi".
    ouputclass instance
    ouputclass instance
    ouputclass instance
    ouputclass instance
    outPortrelationthe Port this MObject wants to be conected to
    outputrelation
    Overviewcomponent diagramThis drawing shows the top level compoents and relations
    pnodenode
    pointattributeidentifying the point where the nodes should be attached
    Posix Threads Abstractionclass viewC++ wrapers for pthreads
    predecessorsrelation
    predicate implclass instance
    Prefetchclass
    Previewclassalternative version of the media data, probably with lower resolution
    procattributeholds the Processor (Render Engine Element) to be built by the current build step
    Proc-Asset Relationsclass diagram
    proc-componentscomponent diagram
    ProcDispatcherclass
    processoperation
    ProcessDataclass
    ProcessingLayerpackage
    Processorclass
    processorartifacta single render pipeline for one segment of the timeline
    ProjectorclassSpecial video processing node used to scale and translate image data.
    projectorartifactvideo ProcNode for scaling and translating image data
    providerrelation
    pulloperation
    PullInputclass
    diff --git a/doc/devel/uml/index_81.html b/doc/devel/uml/index_81.html index 5a521bd2f..6367201fd 100644 --- a/doc/devel/uml/index_81.html +++ b/doc/devel/uml/index_81.html @@ -20,6 +20,7 @@ queryclass view Query System overviewcomponent view query useuse case view +QueryCacheclass QueryHandlerclass QueryHandlerImplclass diff --git a/doc/devel/uml/index_82.html b/doc/devel/uml/index_82.html index 1bade53e8..9b107d854 100644 --- a/doc/devel/uml/index_82.html +++ b/doc/devel/uml/index_82.html @@ -17,15 +17,19 @@ + + + + @@ -42,6 +46,7 @@ + diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index e2f2fcea3..4ea8bf79b 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -55,11 +55,16 @@ + - + + + + + diff --git a/doc/devel/uml/index_84.html b/doc/devel/uml/index_84.html index 14d928057..96532f18f 100644 --- a/doc/devel/uml/index_84.html +++ b/doc/devel/uml/index_84.html @@ -46,9 +46,9 @@ - - + +
    NameKindDescription
    ReadSourceclass
    refPointclass instance
    regoperationregisters an asset object in the internal DB, providing its unique key
    registryrelation@internal Table or DB holding all registered asset instances.
    relativelocationartifactPlacement implemnetaion providing various ways of attaching a MObject to another one
    RelativeLocationclass
    releaseBufferoperation
    RelTypeclassthe possible kinds of RelativePlacements
    relTypeattributethe kind of relation denoted by this Placement
    removeoperationremove the given asset <i>together with all its dependants</i> from the internal DB
    Render Entitiesclass diagram
    Render Mechanicsclass diagram
    Render Processcollaboration diagram
    Render Requestactivity parameter
    RenderEngineclass
    renderengineartifacta complete network of processing nodes usable for rendering
    resolveoperation
    Resolvercomponent
    ResolverBaseclass
    retrieveoperation
    rootCauseoperationIf this exception was caused by a chain of further exceptions,
    return the first one registered in this throw sequence.
    This works only, if every exceptions thrown as a consequence
    of another exception is propperly constructed by passing
    the original exception to the constructor
    Rule Basecomponent
    Rules accessclass diagram
    startattributestartpos in source
    startattributebegin of the timerange covered by this processor
    startattribute
    Stateclass
    Statenode
    Stateclass
    StateProxyclass
    staterelation
    StateAdapterclass
    StateAdapter compositionclass diagram
    StateProxyclass
    stateproxyartifactKey Interface representing a render process and encapsulating state
    std::exceptionclass
    Strategyclass
    Structclasskey abstraction: structural asset
    structartifactkey abstraction: structural asset
    Struct-Asset Relationsclass diagram
    treatoperation
    treatoperation
    treatoperation
    treatoperation
    treatoperation
    treatoperation
    treatoperation
    treatoperation
    TypeHandlerclass
    TypeHandler<Pipe>class
    diff --git a/doc/devel/uml/index_86.html b/doc/devel/uml/index_86.html index e3c5f01a9..3538c8202 100644 --- a/doc/devel/uml/index_86.html +++ b/doc/devel/uml/index_86.html @@ -20,27 +20,25 @@ versionattributeversion number of the thing or concept represented by this asset. Of each unique tuple (name, category, org) there will be only one version in the whole system. Version 0 is reserved for internal purposes. Versions are considered to be ordered, and any higher version is supposed to be fully backwards compatible to all previous versions. VFrameclass vframeartifacta buffer and render process holding a Video frame -vid1class instance -vid1class instance -vid_Aclass instance -vid_Aclass instance -vid_aclass instance -vid_aclass instance +vid1class instance vid_Aclass instance +vid_aclass instance +vid_Aclass instance +vid_Aclass instance +vid_aclass instance videoclass instance -videoclass instance videoclass instance videoclass instance -video1class instance -video1class instance -video1class instance -video1class instance +videoclass instance video1class instance +video1class instance +video1class instance video1class instance +video1class instance +video1class instance Visitableclass visitorpackagesub-namespace for visitor library implementation visitorartifactAcyclic Visitor library -VRenderclassRepresentation of a Video render process. (Encapsulates the video buffers for the actual calculations) vrenderartifactRepresentation of a Video render process diff --git a/doc/devel/uml/index_87.html b/doc/devel/uml/index_87.html index bd2bf3399..616839a54 100644 --- a/doc/devel/uml/index_87.html +++ b/doc/devel/uml/index_87.html @@ -20,6 +20,7 @@ whatoperation whatoperationthe base class of all exceptions thrown by the standard library when to queryuse case diagram +WiringDescriptorclass wiringTemplaterelation wishartifactLocatingPin representing a low-priority directive by the user,
    to be fulfilled only if possible (and after satisfying the
    more important LocatingPins) Wishclass diff --git a/doc/devel/uml/public_operations.html b/doc/devel/uml/public_operations.html index 697d67b52..07fb079d7 100644 --- a/doc/devel/uml/public_operations.html +++ b/doc/devel/uml/public_operations.html @@ -17,11 +17,14 @@ + + + @@ -29,6 +32,7 @@ + @@ -47,26 +51,31 @@ + + + + + + - - + diff --git a/src/common/configrules.hpp b/src/common/configrules.hpp index 0968c88d4..e80ccfa8a 100644 --- a/src/common/configrules.hpp +++ b/src/common/configrules.hpp @@ -48,7 +48,7 @@ #include "common/p.hpp" #include "common/query.hpp" -#include "common/typelistutil.hpp" +#include "common/meta/generator.hpp" #include "common/singletonsubclass.hpp" //TODO: is it sensible to bring in the types explicitly here? (it's not necessary, but may be convenient...) diff --git a/src/common/error.hpp b/src/common/error.hpp index 687425ec2..84140af80 100644 --- a/src/common/error.hpp +++ b/src/common/error.hpp @@ -152,6 +152,7 @@ namespace lumiera /** install our own handler for undeclared exceptions. Will be * called automatically ON_BASIC_INIT when including errror.hpp + * @note it's OK this is defined multiple times... * @see appconfig.hpp */ void install_unexpectedException_handler (); namespace { diff --git a/src/proc/frame.hpp b/src/common/frameid.hpp similarity index 50% rename from src/proc/frame.hpp rename to src/common/frameid.hpp index 239987e97..9cb95eb37 100644 --- a/src/proc/frame.hpp +++ b/src/common/frameid.hpp @@ -1,5 +1,5 @@ /* - FRAME.hpp - Key Abstraction: render process and buffer holding frame data. + FRAMEID.hpp - distinct identification of a single data frame Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,26 +21,36 @@ */ -#ifndef PROC_INTERFACE_FRAME_H -#define PROC_INTERFACE_FRAME_H +#ifndef LUMIERA_FRAMEID_H +#define LUMIERA_FRAMEID_H -namespace proc_interface +namespace lumiera { /** - * TODO: how to relate to Cehteh's Frame entity in the Backend? - * The latter is the fundamental Frame entity, wheras this Object - * rather represents a buffer set containing frame date. + * Identification tuple for addressing frames unambiguosly. + * + * @todo currently (7/08) this is a dummy implementation to find out + * what interface the Proc layer needs. Probably the backend will + * later on define what is actually needed; this header should then + * be replaced by a combined C/C++ header */ - class Frame + class FrameID : boost::totally_ordered { - ///////////////// + long dummy; + public: + FrameID(long dum=0) : dummy(dum) {} + operator long () { return dummy; } + + bool operator< (const FrameID& of) const { return dummy < of.dummy; } + bool operator== (const FrameID& of) const { return dummy == of.dummy; } }; - - -} // namespace proc_interface + + + +} // namespace lumiera #endif diff --git a/src/common/meta/configflags.hpp b/src/common/meta/configflags.hpp new file mode 100644 index 000000000..fa24bfc97 --- /dev/null +++ b/src/common/meta/configflags.hpp @@ -0,0 +1,188 @@ +/* + CONFIGFLAGS.hpp - Building classes based on configuration cases + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +/** @file configflags.hpp + ** Under some circumstances it is necessary to assemble functionality + ** out of elementary building blocks. Especially, this assembly can be + ** expressed as template specialisations directed by a configuration type. + ** Thus, the purpose of this header is to encode flag-like configuraitons + ** as distinct types, which can be used to select such specialisations. + ** Each possible configuration can be encoded as a list of flags, which allows + ** to generate, filter and process those configurations. The final goal is to + ** automatically generate a factory which is able to deliver objects + ** configured according to the situation encoded in the flags. + ** + ** @note currently there is an inherent limitation to configurations defined by + ** a maximum of 5 independant flags. While it is easy to increase this limit, + ** you should consider that the final goal is to genarate template instantiations, + ** which would lead to more and more code bloat with growing number of possible + ** combination. + ** + ** @see proc::engine::config::Strategy usage example + ** @see proc::engine::config::ConfigSelector + ** @see typelist.hpp + ** + */ + + +#ifndef LUMIERA_META_CONFIGFLAGS_H +#define LUMIERA_META_CONFIGFLAGS_H + + +#include "common/meta/typelist.hpp" + + +namespace lumiera { + namespace typelist { + + const size_t CONFIG_FLAGS_MAX = 5; + + + template struct Flag { typedef Flag ID; }; + template<> struct Flag<0> { typedef NullType ID; }; + + + template< char f1=0 + , char f2=0 + , char f3=0 + , char f4=0 + , char f5=0 + > + struct Flags + { + typedef typename Types< typename Flag::ID + , typename Flag::ID + , typename Flag::ID + , typename Flag::ID + , typename Flag::ID + >::List + Tuple; + typedef Tuple List; + }; + + + template< char f1=0 + , char f2=0 + , char f3=0 + , char f4=0 + , char f5=0 + > + struct Config ///< distinct type representing a configuration + { + typedef typename Flags::Tuple Flags; + typedef Flags List; + }; + + + + template + struct ConfigSetFlag; ///< set (prepend) the Flag to the given config + + template< char Fl + , char f1 + , char f2 + , char f3 + , char f4 + , char IGN + > + struct ConfigSetFlag > + { + typedef Config Config; + }; + + + + /** build a configuration type for the given list-of-flags */ + template > + struct DefineConfigByFlags + { + typedef CONF Config; + typedef Config Type; + }; + template + struct DefineConfigByFlags< Node,FLAGS>, CONF> + { + typedef typename ConfigSetFlag< Fl + , typename DefineConfigByFlags::Config + >::Config Config; + typedef Config Type; + }; + + + /** + * Helper for calculating values and for + * invoking runtime code based on a given FlagTuple. + * Can also be used on a Typelist of several Configs. + * The latter case is typically used to invoke an operation + * while ennumerating all Flag-Configurations defined in Code. + * An example would be to build (at runtime) an dispatcher table. + * Explanation: For the Case covering a List of Configs, we provide + * a templated visitaion function, which can accept a functor object + * to be invoked on each Configuration. + */ + template + struct FlagInfo; + + template + struct FlagInfo, FLAGS> > + { + enum{ BITS = MAX(ff, FlagInfo::BITS) + , CODE = (1<::CODE + }; + }; + template<> + struct FlagInfo + { + enum{ BITS = 0 + , CODE = 0 + }; + + template + static typename FUNC::Ret + accept (FUNC& functor) + { + return functor.done(); + } + }; + template + struct FlagInfo > + { + typedef typename CONF::Flags ThisFlags; + enum{ BITS = MAX (char(FlagInfo::BITS), char(FlagInfo::BITS)) + }; + + template + static typename FUNC::Ret + accept (FUNC& functor) + { + functor.template visit(FlagInfo::CODE); + return FlagInfo::accept (functor); + } + }; + + + + } // namespace typelist + +} // namespace lumiera +#endif diff --git a/src/common/typelistutil.hpp b/src/common/meta/generator.hpp similarity index 86% rename from src/common/typelistutil.hpp rename to src/common/meta/generator.hpp index 3fb6a531e..59f340b5d 100644 --- a/src/common/typelistutil.hpp +++ b/src/common/meta/generator.hpp @@ -1,5 +1,5 @@ /* - TYPELISTUTIL.hpp - metaprogramming utilities for lists-of-types + GENERATOR.hpp - metaprogramming utilities for generating classes and interfaces Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -38,7 +38,7 @@ This code is heavily inspired by */ -/** @file typelistutil.hpp +/** @file generator.hpp ** Helpers for working with lumiera::typelist::Types (i.e. lists-of-types). ** The main purpose is to build interfaces and polymorphic implementations ** (using virtual functions) based on templated Types or Collections of types, @@ -50,10 +50,10 @@ This code is heavily inspired by */ -#ifndef LUMIERA_TYPELISTUTIL_H -#define LUMIERA_TYPELISTUTIL_H +#ifndef LUMIERA_META_GENERATOR_H +#define LUMIERA_META_GENERATOR_H -#include "common/typelist.hpp" +#include "common/meta/typelist.hpp" @@ -196,42 +196,6 @@ namespace lumiera }; - /** - * Metafunction counting the number of Types in the collection - */ - template - struct count; - template<> - struct count - { - enum{ value = 0 }; - }; - template - struct count > - { - enum{ value = 1 + count::value }; - }; - - /** - * Metafunction " max( sizeof(T) ) for T in TYPES " - */ - template - struct maxSize; - template<> - struct maxSize - { - enum{ value = 0 }; - }; - template - struct maxSize > - { - enum{ thisval = sizeof(TY) - , nextval = maxSize::value - , value = nextval > thisval? nextval:thisval - }; - }; - - } // namespace typelist } // namespace lumiera diff --git a/src/common/typelist.hpp b/src/common/meta/typelist.hpp similarity index 94% rename from src/common/typelist.hpp rename to src/common/meta/typelist.hpp index f358a605e..c2d4568d0 100644 --- a/src/common/typelist.hpp +++ b/src/common/meta/typelist.hpp @@ -53,8 +53,8 @@ This code is heavily inspired by */ -#ifndef LUMIERA_TYPELIST_H -#define LUMIERA_TYPELIST_H +#ifndef LUMIERA_META_TYPELIST_H +#define LUMIERA_META_TYPELIST_H @@ -64,11 +64,15 @@ namespace lumiera namespace typelist { - class NullType { }; + class NullType + { + typedef NullType List; + }; template struct Node { + typedef Node List; typedef H Head; typedef T Tail; }; @@ -113,6 +117,8 @@ namespace lumiera }; + typedef Node NodeNull; + } // namespace typelist diff --git a/src/common/meta/typelistutil.hpp b/src/common/meta/typelistutil.hpp new file mode 100644 index 000000000..3a0d56284 --- /dev/null +++ b/src/common/meta/typelistutil.hpp @@ -0,0 +1,213 @@ +/* + TYPELISTUTIL.hpp - Utils for working with lists-of-types + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef LUMIERA_META_TYPELISTUTIL_H +#define LUMIERA_META_TYPELISTUTIL_H + + + +#include "common/meta/typelist.hpp" + +namespace lumiera { + namespace typelist { + + + /** + * Metafunction counting the number of Types in the collection + */ + template + struct count; + template<> + struct count + { + enum{ value = 0 }; + }; + template + struct count > + { + enum{ value = 1 + count::value }; + }; + + /** + * Metafunction " max( sizeof(T) ) for T in TYPES " + */ + template + struct maxSize; + template<> + struct maxSize + { + enum{ value = 0 }; + }; + template + struct maxSize > + { + enum{ thisval = sizeof(TY) + , nextval = maxSize::value + , value = nextval > thisval? nextval:thisval + }; + }; + + + /** apply a transformation (template) to each type in the list */ + template class _TRANS_> + struct Apply { typedef TY List; }; + + template< class TY, class TYPES + , template class _TRANS_ + > + struct Apply, _TRANS_ > { typedef Node< typename _TRANS_::Type + , typename Apply::List + > List; }; + + + template + struct CondNode { typedef TAIL Next; }; + + template + struct CondNode { typedef Node Next; }; + + /** filter away those types which don't fulfill a predicate metafunction */ + template< class TYPES + , template class _P_ ///< a template providing a boolean member \c ::value + > + struct Filter; + + template class _P_> + struct Filter { typedef NullType List; }; + + template< class TY, class TYPES + , template class _P_ + > + struct Filter,_P_> { typedef typename CondNode< _P_::value + , TY + , typename Filter::List + >::Next + List; }; + + + /** append lists-of-types */ + template + struct Append { typedef Node::List> List; }; + + template< class TY, class TYPES + , class TAIL + > + struct Append, TAIL> { typedef Node::List> List; }; + + template + struct Append > { typedef Node List; }; + + template + struct Append, NullType> { typedef Node List; }; + + template + struct Append { typedef Node List; }; + + template + struct Append { typedef Node List; }; + + template<> + struct Append { typedef NullType List; }; + + + + /** + * prefix each of the elements, + * yielding a list-of lists-of-types + */ + template + struct PrefixAll { typedef Node< typename Append::List, NullType> List; }; + + template + struct PrefixAll { typedef NullType List; }; + + template + struct PrefixAll { typedef Node< typename Append::List, NullType> List; }; + + template< class T + , class TY, class TYPES + > + struct PrefixAll > { typedef Node< typename Append::List + , typename PrefixAll::List + > List; }; + + + + + template + struct Distribute { typedef typename PrefixAll::List List; }; + + template + struct Distribute { typedef NullType List; }; + + template< class TY, class TYPES + , class TAIL + > + struct Distribute,TAIL> { typedef typename Append< typename PrefixAll::List + , typename Distribute::List + >::List + List; }; + + + + /** use a permutation generator + * for creating a list of all possible combinations + */ + template< class X + , template class _PERMU_> + struct Combine { typedef typename Distribute< typename _PERMU_::List + , Node + >::List List; }; + template< template class _PERMU_> + struct Combine { typedef Node List; }; + + template< class TY, class TYPES + , template class _PERMU_> + struct Combine,_PERMU_> { typedef typename Distribute< typename _PERMU_::List + , typename Combine::List + >::List List; }; + + /** permutation generator for the Combine metafunction, + * yielding an "on" and "off" case + */ + template + struct FlagOnOff + { + typedef Node > List; + }; + + + /** generate all possible on-off combinations of the given flags */ + template + struct CombineFlags + { + typedef typename Combine::List List; + }; + + + + + } // namespace typelist + +} // namespace lumiera +#endif diff --git a/src/common/meta/util.hpp b/src/common/meta/util.hpp new file mode 100644 index 000000000..b01a412fa --- /dev/null +++ b/src/common/meta/util.hpp @@ -0,0 +1,76 @@ +/* + UTIL.hpp - metaprogramming helpers and utilities + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef LUMIERA_META_UTIL_H +#define LUMIERA_META_UTIL_H + + + +namespace lumiera { + + + /* types for figuring out the overload resolution chosen by the compiler */ + + typedef char Yes_t; + struct No_t { char padding[8]; }; + + + + namespace typelist { + + /** semi-automatic detection if an instantiation is possible. + * Requires help by the template to be tested, which needs to define + * a typedef member \c is_defined. The embedded metafunction Test can be used + * as a predicate for filtering types which may yield a valid instantiation + * of the candidate template in question. + * \par + * A fully automated solution for this problem is impossible by theoretic reasons. + * Any non trivial use of such a \c is_defined trait would break the "One Definition Rule", + * as the state of any type can change from "partially defined" to "fully defined" over + * the course of any translation unit. Thus, even if there may be a \em solution out there, + * we can expect it to break at some point by improvements/fixes to the C++ Language. + */ + template class _CandidateTemplate_> + struct Instantiation + { + + template + class Test + { + typedef _CandidateTemplate_ Instance; + + template + static Yes_t check(typename U::is_defined *); + template + static No_t check(...); + + public: + static const bool value = (sizeof(Yes_t)==sizeof(check(0))); + }; + }; + + + } // namespace typelist + +} // namespace lumiera +#endif diff --git a/src/common/util.hpp b/src/common/util.hpp index 7f8704554..c71ba3b6a 100644 --- a/src/common/util.hpp +++ b/src/common/util.hpp @@ -237,4 +237,8 @@ namespace util * and we probably will enforce this design rule in future. */ #define INSTANCEOF(CLASS, EXPR) (dynamic_cast (EXPR)) +/** the inevitalbe MAX macro, sometimes still necessary in template code */ +#define MAX(A,B) (A < B) ? (B) : (A) + + #endif /*UTIL_HPP_*/ diff --git a/src/common/variant.hpp b/src/common/variant.hpp index 561b7149c..751c2d9fc 100644 --- a/src/common/variant.hpp +++ b/src/common/variant.hpp @@ -41,7 +41,8 @@ #define LUMIERA_VARIANT_H -#include "common/typelistutil.hpp" +#include "common/meta/typelistutil.hpp" +#include "common/meta/generator.hpp" #include diff --git a/src/common/visitor.hpp b/src/common/visitor.hpp index 3d22f11e6..49bbcedb5 100644 --- a/src/common/visitor.hpp +++ b/src/common/visitor.hpp @@ -79,7 +79,7 @@ Credits for many further implementation ideas go to #include "common/visitorpolicies.hpp" #include "common/visitordispatcher.hpp" -#include "common/typelist.hpp" +#include "common/meta/typelist.hpp" namespace lumiera diff --git a/src/common/wrapperptr.hpp b/src/common/wrapperptr.hpp index e17963eff..81afa1177 100644 --- a/src/common/wrapperptr.hpp +++ b/src/common/wrapperptr.hpp @@ -29,7 +29,7 @@ #include "common/variant.hpp" #include "common/accesscasted.hpp" -#include "common/typelist.hpp" +#include "common/meta/typelist.hpp" #include "proc/mobject/placement.hpp" #include "common/p.hpp" diff --git a/src/gui/lumiera_ui.rc b/src/gui/lumiera_ui.rc new file mode 100644 index 000000000..428b7bed4 --- /dev/null +++ b/src/gui/lumiera_ui.rc @@ -0,0 +1,157 @@ +# +# This is the GTK style file for Lumiera +# +# + +#---------- Styles for Standard Widgets ----------# + +style "medium_text" +{ + font_name = "sans 10" +} + +style "medium_bold_entry" = "medium_text" +{ + fg[NORMAL] = { 0.70, 0.70, 0.70 } + fg[ACTIVE] = { 0.70, 0.70, 0.70 } + + bg[NORMAL] = { 0.35, 0.35, 0.40 } + + base[NORMAL] = { 0, 0, 0 } + base[ACTIVE] = { 0, 0, 0 } + base[SELECTED] = { 0, 0, 0 } +} + +style "default_base" = "medium_text" +{ + GtkWidget::cursor_color = {1.0, 1.0, 1.0 } + GtkButton::default_border = { 0, 0, 0, 0 } + GtkButton::default_outside_border = { 0, 0, 0, 0 } + GtkTreeView::vertical-padding = 0 + GtkTreeView::horizontal-padding = 0 + GtkTreeView::even-row-color = { 0, 0, 0 } + GtkTreeView::odd-row-color = { 0, 0, 0 } + + fg[NORMAL] = { 0.80, 0.80, 0.80 } + fg[ACTIVE] = { 0.80, 0.80, 0.80 } + fg[PRELIGHT] = { 1.0, 1.0, 1.0 } + fg[INSENSITIVE] = { 0.80, 0.80, 0.80 } + fg[SELECTED] = { 0.80, 0.80, 0.80 } + + bg[NORMAL] = { 0.35, 0.35, 0.40 } + bg[ACTIVE] = { 0.35, 0.35, 0.40 } + bg[PRELIGHT] = "#565690" + bg[INSENSITIVE] = { 0.10, 0.10, 0.10 } + bg[SELECTED] = { 0, 0.40, 0.60 } + + text[NORMAL] = { 0.80, 0.80, 0.80 } + text[ACTIVE] = { 0.80, 0.80, 0.80 } + text[PRELIGHT] = { 0.80, 0.80, 0.80 } + text[INSENSITIVE] = { 0.80, 0.80, 0.80} + text[SELECTED] = { 1.0, 1.0, 1.0 } + + base[ACTIVE] = "#272a2f" + base[NORMAL] = "#1a1e20" + base[PRELIGHT] = { 0.20, 0.20, 0.20 } + base[INSENSITIVE] = "#4c5159" + base[SELECTED] = { 0.25, 0.25, 0.25 } + + engine "clearlooks" + { + menubarstyle = 2 # 0 = flat, 1 = sunken, 2 = flat gradient +# menuitemstyle = 1 # 0 = flat, 1 = 3d-ish (gradient), 2 = 3d-ish (button) +# listviewitemstyle = 1 # 0 = flat, 1 = 3d-ish (gradient) +# progressbarstyle = 1 # 0 = candy bar, 1 = fancy candy bar, 2 = flat + } +} + +style "default_buttons_menus" +{ + font_name = "sans 10" + fg[ACTIVE] = { 1.0, 1.0, 1.0 } + + bg[NORMAL] = { 0.30, 0.30, 0.35 } + bg[ACTIVE] = "#565690" + bg[PRELIGHT] = { 0.15, 0.15, 0.20 } + bg[INSENSITIVE] = { 0.15, 0.15, 0.20 } + bg[SELECTED] = { 0.15, 0.15, 0.20 } +} + +style "lumiera_adjusters" = "default_buttons_menus" +{ + fg[NORMAL] = { 0.80, 0.80, 0.80 } + fg[ACTIVE] = { 0.80, 0.80, 0.80 } + fg[PRELIGHT] = { 1.0, 1.0, 1.0 } + fg[INSENSITIVE] = { 0.80, 0.80, 0.80 } + fg[SELECTED] = { 0.80, 0.80, 0.80 } + + bg[NORMAL] = { 0.35, 0.35, 0.40 } + bg[ACTIVE] = { 0.35, 0.35, 0.40 } + bg[PRELIGHT] = "#565690" + bg[INSENSITIVE] = { 0.10, 0.10, 0.10 } + bg[SELECTED] = { 0, 0.40, 0.60 } +} + +style "lumiera_progressbars" = "default_buttons_menus" +{ + bg[NORMAL] = { 0, 0, 0 } + bg[PRELIGHT] = { 0.00, 0.36, 0.40 } +} + +style "lumiera_button" = "default_buttons_menus" +{ + xthickness = 1 + ythickness = 1 +} + +style "tearoff_arrow" = "medium_bold_entry" +{ + fg[NORMAL] = { 0.80, 0.80, 0.80 } + fg[PRELIGHT] = { 0.80, 0.80, 0.80 } + bg[NORMAL] = { 0.80, 0.80, 0.80 } + bg[PRELIGHT] = { 0.80, 0.80, 0.80 } +} + +class "GtkWidget" style:highest "default_base" +class "GtkScrollbar" style:highest "lumiera_adjusters" +class "GtkLabel" style:highest "default_buttons_menus" +class "GtkButton" style:highest "lumiera_button" +class "GtkArrow" style:highest "tearoff_arrow" +class "GtkProgressBar" style:highest "lumiera_progressbars" + +#---------- Styles for Lumiera Widgets ----------# + +style "timeline_body" +{ + gtkmm__CustomObject_TimelineBody::background = "#7E838B" +} + +style "timeline_ruler" = "default_base" +{ + font_name = "sans 8" + gtkmm__CustomObject_TimelineRuler::height = 18 + gtkmm__CustomObject_TimelineRuler::major_tick_height = 18 + gtkmm__CustomObject_TimelineRuler::minor_long_tick_height = 6 + gtkmm__CustomObject_TimelineRuler::minor_short_tick_height = 3 + gtkmm__CustomObject_TimelineRuler::annotation_horz_margin = 3 + gtkmm__CustomObject_TimelineRuler::annotation_vert_margin = 0 + gtkmm__CustomObject_TimelineRuler::min_division_width = 100 + gtkmm__CustomObject_TimelineRuler::mouse_chevron_size = 5 +} + +style "timeline_header_base" = "default_base" +{ +# fg[NORMAL] = { 0.77, 0.77, 0.72 } +# bg[NORMAL] = { 0.18, 0.19, 0.22 } +# bg[ACTIVE] = { 0.20, 0.20, 0.20 } +# bg[PRELIGHT] = { 0.20, 0.20, 0.20 } +# bg[INSENSITIVE] = { 0.20, 0.20, 0.20 } +# bg[SELECTED] = { 0.20, 0.20, 0.20 } +} + +class "gtkmm__CustomObject_TimelineBody" style:highest "timeline_body" +class "gtkmm__CustomObject_TimelineRuler" style:highest "timeline_ruler" + +widget "*TimelineHeaderBaseUnselected" style:highest "timeline_header_base" + + diff --git a/src/lib/appconfig.hpp b/src/lib/appconfig.hpp index b82c3fa2b..a69336d78 100644 --- a/src/lib/appconfig.hpp +++ b/src/lib/appconfig.hpp @@ -129,7 +129,8 @@ namespace lumiera * All other lables are just arbitrary (string) constants and it * is necessary that "someone" cares to fire off the lifcycle events * at the right place. For example, lumiera-main (and the test runner) - * calls \c Appconfig::instance().execute(ON_GLOBAL_INIT) (and..SHUTDOWN) + * calls \c Appconfig::instance().execute(ON_GLOBAL_INIT) (and..SHUTDOWN) + * @note duplicate or repeated calls with the same callback are a NOP */ class LifecycleHook : private noncopyable diff --git a/src/proc/engine/aframe.hpp b/src/proc/engine/aframe.hpp deleted file mode 100644 index 0d77e15ca..000000000 --- a/src/proc/engine/aframe.hpp +++ /dev/null @@ -1,41 +0,0 @@ -/* - AFRAME.hpp - buffer holding a Audio samples for the render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_AFRAME_H -#define ENGINE_AFRAME_H - -#include "proc/frame.hpp" - - - -namespace engine - { - - - class AFrame : public proc_interface::Frame - {}; - - - -} // namespace engine -#endif diff --git a/src/proc/engine/arender.hpp b/src/proc/engine/arender.hpp deleted file mode 100644 index 79c70c460..000000000 --- a/src/proc/engine/arender.hpp +++ /dev/null @@ -1,44 +0,0 @@ -/* - ARENDER.hpp - Representation of a Audio Render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_ARENDER_H -#define ENGINE_ARENDER_H - -#include "proc/stateproxy.hpp" - - - -namespace engine - { - - - /** - * Representation of a Audio render process - */ - class ARender : public proc_interface::StateProxy - {}; - - - -} // namespace engine -#endif diff --git a/src/proc/engine/arender.cpp b/src/proc/engine/buffhandle.cpp similarity index 87% rename from src/proc/engine/arender.cpp rename to src/proc/engine/buffhandle.cpp index ac7171998..30ae603e2 100644 --- a/src/proc/engine/arender.cpp +++ b/src/proc/engine/buffhandle.cpp @@ -1,5 +1,5 @@ /* - ARender - Representation of a Audio Render process + BuffHandle - Buffer handling support for the render engine Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,14 +21,12 @@ * *****************************************************/ -#include "proc/engine/arender.hpp" +#include "proc/engine/buffhandle.hpp" -namespace engine - { - - /** */ +namespace engine { + /** */ } // namespace engine diff --git a/src/proc/engine/buffhandle.hpp b/src/proc/engine/buffhandle.hpp new file mode 100644 index 000000000..51ce1c135 --- /dev/null +++ b/src/proc/engine/buffhandle.hpp @@ -0,0 +1,104 @@ +/* + BUFFHANDLE.hpp - Buffer handling support for the render engine + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + +/** @file buffhandle.hpp + ** Various bits needed to support the buffer management within the render nodes. + ** When pulling data from predecessor nodes and calculating new data, each render node + ** needs several input and output buffers. These may be allocated and provided by several + ** different "buffer providers" (for example the frame cache). For accessing those buffers, + ** the node needs to keep a table of buffer pointers, and for releasing the buffers later + ** on, we need some handles. The usage pattern of those buffer pointer tables is stack-like, + ** thus it makes sense to utilize a single large buffer pointer array per pull() calldown + ** sequence and dynamically claim small chunks for each node. + ** + ** @see nodeoperation.hpp + ** @see bufftable.hpp storage for the buffer table + ** @see engine::Invocation + */ + +#ifndef ENGINE_BUFFHANDLE_H +#define ENGINE_BUFFHANDLE_H + + +#include "common/error.hpp" + + +namespace engine { + + + + /** + * Handle for a buffer for processing data, abstracting away the actual implementation. + * The real buffer pointer can be retrieved by dereferencing this smart-handle class. + */ + struct BuffHandle + { + typedef float Buff; + typedef Buff* PBuff;//////TODO define the Buffer type(s) + + PBuff + operator->() const + { + return pBuffer_; + } + Buff& + operator* () const + { + ENSURE (pBuffer_); + return *pBuffer_; + } + + protected: + PBuff pBuffer_; + long sourceID_; + }; + + + /** + * Buffer Type information. + * Given a BufferDescriptor, it is possible to allocate a buffer + * of suitable size and type by using State::allocateBuffer(). + */ + struct BufferDescriptor + { + char typeID_; ///////TODO define the Buffer type(s) + }; + + + class ProcNode; + typedef ProcNode* PNode; + + + struct ChannelDescriptor ///////TODO collapse this with BufferDescriptor? + { + BufferDescriptor bufferType; + }; + + struct InChanDescriptor : ChannelDescriptor + { + PNode dataSrc; ///< the ProcNode to pull this input from + uint srcChannel; ///< output channel to use on the predecessor node + }; + + +} // namespace engine +#endif diff --git a/src/proc/engine/bufftable.hpp b/src/proc/engine/bufftable.hpp new file mode 100644 index 000000000..ac1329265 --- /dev/null +++ b/src/proc/engine/bufftable.hpp @@ -0,0 +1,162 @@ +/* + BUFFTABLE.hpp - Table of buffer pointers to be used by the render nodes + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef ENGINE_BUFFHTABLE_H +#define ENGINE_BUFFHTABLE_H + + +#include "common/error.hpp" +#include "proc/engine/buffhandle.hpp" +#include "proc/engine/procnode.hpp" + +#include +#include +#include + + + +namespace engine { + + using std::pair; + using std::vector; + + + /** + * Tables of buffer handles and corresponding dereferenced buffer pointers. + * Used within the invocation of a processing node to calculate data. + * The tables are further differentiated into input data buffers and output + * data buffers. The tables are supposed to be implemented as bare "C" arrays, + * thus the array of real buffer pointers can be fed directly to the + * processing function of the respective node. + */ + struct BuffTable + { + typedef BuffHandle * PHa; + typedef BuffHandle::PBuff * PBu; + typedef pair Chunk; + + PHa outHandle; + PHa inHandle; + PBu outBuff; + PBu inBuff; + }; + + + class BuffTableStorage + { + vector hTab_; + vector pTab_; + size_t level_; + + public: + BuffTableStorage (const size_t maxSiz) + : hTab_(maxSiz), + pTab_(maxSiz), + level_(0) + { } + + ~BuffTableStorage() { ASSERT (0==level_, "buffer management logic broken."); } + + protected: + + friend class BuffTableChunk; + + /** allocate the given number of slots + * starting at current level to be used + * by the newly created BuffTableChunk + */ + BuffTable::Chunk + claim (uint slots) + { + ASSERT (pTab_.size() == hTab_.size()); + REQUIRE (level_+slots <= hTab_.size()); + + size_t prev_level (level_); + level_ += slots; + return std::make_pair (&hTab_[prev_level], + &pTab_[prev_level]); + } + + void + release (uint slots) + { + ASSERT (slots <= level_); + REQUIRE (level_ <= hTab_.size()); + REQUIRE (level_ <= pTab_.size()); + + level_ -= slots; + } + + bool + level_check (BuffTable::Chunk& prev_level) + { + return prev_level.first == &hTab_[level_] + && prev_level.second == &pTab_[level_]; + } + }; + + + /** + * to be allocated on the stack while evaluating a ProcNode#pull() call. + * The "current" State (StateProxy) maintains a BuffTableStorage (=pool), + * which can be used to crate such chunks. The claiming and releasing of + * slots in the BuffTableStorage is automatically tied to BuffTableChunk + * object's lifecycle. + */ + class BuffTableChunk + : public BuffTable, + boost::noncopyable + { + const uint siz_; + BuffTable::Chunk tab_; + BuffTableStorage& sto_; + + public: + BuffTableChunk (WiringDescriptor const& wd, BuffTableStorage& storage) + : siz_(wd.getNrI() + wd.getNrO()), + tab_(storage.claim (siz_)), + sto_(storage) + { + const uint nrO(wd.getNrO()); + + // Setup the public visible table locations + this->outHandle = &tab_.first[ 0 ]; + this->inHandle = &tab_.first[nrO]; + this->outBuff = &tab_.second[ 0 ]; + this->inBuff = &tab_.second[nrO]; + } + + ~BuffTableChunk () + { + sto_.release (siz_); + ASSERT ( sto_.level_check (tab_), + "buffer management logic broken."); + } + }; + + + + + +} // namespace engine +#endif diff --git a/src/proc/engine/codecadapter.cpp b/src/proc/engine/codecadapter.cpp deleted file mode 100644 index b65694679..000000000 --- a/src/proc/engine/codecadapter.cpp +++ /dev/null @@ -1,30 +0,0 @@ -/* - CodecAdapter - Processing Node for (de)coding media data - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/codecadapter.hpp" - -namespace engine - { - - -} // namespace engine diff --git a/src/proc/engine/codecadapter.hpp b/src/proc/engine/codecadapter.hpp deleted file mode 100644 index 724763eaa..000000000 --- a/src/proc/engine/codecadapter.hpp +++ /dev/null @@ -1,49 +0,0 @@ -/* - CODECADAPTER.hpp - Processing Node for (de)coding media data - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_CODECADAPTER_H -#define ENGINE_CODECADAPTER_H - -#include "proc/engine/trafo.hpp" - - - -namespace engine - { - - - /** - * Adapter for wiring an externally loaded - * codec into the render pipeline. The decoding - * process thus is integrated into the framework - * of the Renderengine, while the actual implementation - * can be delegated to an external library accessed - * through Lumiera's data backend. - */ - class CodecAdapter : public Trafo - {}; - - - -} // namespace engine -#endif diff --git a/src/proc/engine/exitnode.cpp b/src/proc/engine/exitnode.cpp deleted file mode 100644 index 8c26b7cd9..000000000 --- a/src/proc/engine/exitnode.cpp +++ /dev/null @@ -1,33 +0,0 @@ -/* - ExitNode - special Processing Node providing "pullable" output - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/exitnode.hpp" - -namespace engine - { - - /** */ - - - -} // namespace engine diff --git a/src/proc/engine/glbuf.cpp b/src/proc/engine/glbuf.cpp deleted file mode 100644 index 6970a3114..000000000 --- a/src/proc/engine/glbuf.cpp +++ /dev/null @@ -1,34 +0,0 @@ -/* - GLBuf - a buffer and render process holding a Video frame for OpenGL rendering - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/glbuf.hpp" - -namespace engine - { - - /** */ - - - - -} // namespace engine diff --git a/src/proc/engine/glbuf.hpp b/src/proc/engine/glbuf.hpp deleted file mode 100644 index 8e8ee2ea5..000000000 --- a/src/proc/engine/glbuf.hpp +++ /dev/null @@ -1,39 +0,0 @@ -/* - GLBUF.hpp - a buffer and render process holding a Video frame for OpenGL rendering - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_GLBUF_H -#define ENGINE_GLBUF_H - -#include "proc/frame.hpp" - - - -namespace engine - { - - - class GLBuf : public proc_interface::Frame - {}; - -} // namespace engine -#endif diff --git a/src/proc/engine/glpipe.cpp b/src/proc/engine/glpipe.cpp deleted file mode 100644 index 9d4d28b48..000000000 --- a/src/proc/engine/glpipe.cpp +++ /dev/null @@ -1,34 +0,0 @@ -/* - GLPipe - specialized connection element for handling OpenGL implementation details - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/glpipe.hpp" - -namespace engine - { - - /** */ - - - - -} // namespace engine diff --git a/src/proc/engine/glpipe.hpp b/src/proc/engine/glpipe.hpp deleted file mode 100644 index 39a98a7ab..000000000 --- a/src/proc/engine/glpipe.hpp +++ /dev/null @@ -1,46 +0,0 @@ -/* - GLPIPE.hpp - specialized connection element for handling OpenGL implementation details - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_GLPIPE_H -#define ENGINE_GLPIPE_H - -#include "proc/engine/link.hpp" - - - -namespace engine - { - - - /** - * specialized connection node used to handle the transfer of OpenGL data - * from a image bitmap into texture form. - */ - class GLPipe : public Link - {}; - - - - -} // namespace engine -#endif diff --git a/src/proc/engine/glrender.cpp b/src/proc/engine/glrender.cpp deleted file mode 100644 index 32420201b..000000000 --- a/src/proc/engine/glrender.cpp +++ /dev/null @@ -1,33 +0,0 @@ -/* - GLRender - Representation of a OpenGL accellerated Video render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/glrender.hpp" - -namespace engine - { - - /** */ - - - -} // namespace engine diff --git a/src/proc/engine/glrender.hpp b/src/proc/engine/glrender.hpp deleted file mode 100644 index e9c73c3a3..000000000 --- a/src/proc/engine/glrender.hpp +++ /dev/null @@ -1,42 +0,0 @@ -/* - GLRENDER.hpp - Representation of a OpenGL accellerated Video render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_GLRENDER_H -#define ENGINE_GLRENDER_H - -#include "proc/stateproxy.hpp" - - - -namespace engine - { - - - /** - * Representation of a OpenGL accelerated Video render process - */ - class GLRender : public proc_interface::StateProxy - {}; - -} // namespace engine -#endif diff --git a/src/proc/engine/hub.cpp b/src/proc/engine/hub.cpp deleted file mode 100644 index 394d24197..000000000 --- a/src/proc/engine/hub.cpp +++ /dev/null @@ -1,34 +0,0 @@ -/* - Hub - special ProcNode used to build data distributing connections - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/hub.hpp" - -namespace engine - { - - /** */ - - - - -} // namespace engine diff --git a/src/proc/engine/hub.hpp b/src/proc/engine/hub.hpp deleted file mode 100644 index b6ec69fcb..000000000 --- a/src/proc/engine/hub.hpp +++ /dev/null @@ -1,44 +0,0 @@ -/* - HUB.hpp - special ProcNode used to build data distributing connections - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_HUB_H -#define ENGINE_HUB_H - -#include "proc/engine/procnode.hpp" - - - -namespace engine - { - - - class Hub : public ProcNode - {}; - ///TODO: seems rather we don't need this one anymore?? - //////// to be decided after the implementing the basic render engine.... - - - - -} // namespace engine -#endif diff --git a/src/proc/engine/link.hpp b/src/proc/engine/link.hpp index ad2f3a625..d677fca9c 100644 --- a/src/proc/engine/link.hpp +++ b/src/proc/engine/link.hpp @@ -40,6 +40,10 @@ namespace engine */ class Link : public ProcNode { + Link (WiringDescriptor const& wd) + : ProcNode(wd) + { } + ///////TODO: flatten hierarchy if we don't have common functionallity for all Link-Subclasses ///////TODO: can be decdiede when we know more how to handle OpenGL rendering }; diff --git a/src/proc/engine/aframe.cpp b/src/proc/engine/nodefactory.cpp similarity index 67% rename from src/proc/engine/aframe.cpp rename to src/proc/engine/nodefactory.cpp index e8713897b..d439232f3 100644 --- a/src/proc/engine/aframe.cpp +++ b/src/proc/engine/nodefactory.cpp @@ -1,5 +1,5 @@ /* - AFrame - buffer holding a Audio samples for the render process + NodeFactory - Interface for creating processing nodes of variouos kinds Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,14 +21,21 @@ * *****************************************************/ -#include "proc/engine/aframe.hpp" +#include "proc/engine/nodefactory.hpp" +#include "proc/mobject/session/effect.hpp" -namespace engine +namespace engine { + + using mobject::Placement; + using mobject::session::Effect; + + + /** create a processing node able to render an effect */ + PTrafo + NodeFactory::operator() (Placement const&) { - - /** */ - - + UNIMPLEMENTED ("create proc node for Effect/Plugin"); + } } // namespace engine diff --git a/src/proc/engine/exitnode.hpp b/src/proc/engine/nodefactory.hpp similarity index 53% rename from src/proc/engine/exitnode.hpp rename to src/proc/engine/nodefactory.hpp index 1cb6e51c2..7abae3340 100644 --- a/src/proc/engine/exitnode.hpp +++ b/src/proc/engine/nodefactory.hpp @@ -1,5 +1,5 @@ /* - EXITNODE.hpp - special Processing Node providing "pullable" output + NODEFACTORY.hpp - Interface for creating processing nodes of variouos kinds Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,25 +21,46 @@ */ -#ifndef ENGINE_EXITNODE_H -#define ENGINE_EXITNODE_H +#ifndef ENGINE_NODEFACTORY_H +#define ENGINE_NODEFACTORY_H #include "proc/engine/procnode.hpp" +#include "proc/mobject/placement.hpp" -namespace engine - { +namespace mobject { + namespace session { + + class Clip; + class Effect; + typedef Placement PEffect; + // TODO: class Transition; + + } // namespace mobject::session + +} // namespace mobject + + +namespace engine { + + using std::vector; + + class Trafo; + typedef Trafo* PTrafo; ///< @note ProcNode is handled by pointer and bulk allocated/dealocated /** - * The output end of each render pipeline. - * Pulling from such exit nodes actually ivokes the render process + * Create processing nodes based on given objects of the high-level model. */ - class ExitNode : public ProcNode - {}; - - + class NodeFactory + { + + public: + + PTrafo operator() (mobject::session::PEffect const&); + + }; } // namespace engine #endif diff --git a/src/proc/engine/nodeinvocation.hpp b/src/proc/engine/nodeinvocation.hpp new file mode 100644 index 000000000..8b350d382 --- /dev/null +++ b/src/proc/engine/nodeinvocation.hpp @@ -0,0 +1,216 @@ +/* + NODEINVOCATION.hpp - Organize the invocation state within a single pull() call + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + +/** @file nodeinvocation.hpp + ** Organize the state related to the invocation of s single ProcNode::pull() call + ** This header defines part of the "glue" which holds together the render node network + ** and enables to pull result frames from the nodes. Doing so requires some invocation + ** local state to be maintained, especially a table of buffers used to carry out the + ** calculations. Further, getting the input buffers filled requires to issue recursive + ** \c pull() calls, which on the whole creates a stack-like assembly of local invocation + ** state. + ** The actual steps to be carried out for a \c pull() call are dependant on the configuration + ** of the node to pull. Each node has been preconfigured by the builder with a WiringDescriptor + ** and a concrete type of a StateAdapter. The actual sequence of steps is defined in the header + ** nodeoperation.hpp out of a set of basic operation steps. These steps all use the passed in + ** Invocation object (a sub-interface of StateAdapter) to access the various aspects of the + ** invocation state. + ** + ** \par composition of the Invocation State + ** For each individual ProcNode#pull() call, the WiringAdapter#callDown() builds an StateAdapter + ** instance directly on the stack, managing the actual buffer pointers and state references. Using this + ** StateAdapter, the predecessor nodes are pulled. The way these operations are carried out is encoded + ** in the actual StateAdapter type known to the NodeWiring (WiringAdapter) instance. All of these actual + ** StateAdapter types are built as implementing the engine::State interface. + ** + ** @see engine::ProcNode + ** @see engine::StateProxy + ** @see engine::BuffTable + ** @see nodewiring.hpp interface for building/wiring the nodes + ** + */ + +#ifndef ENGINE_NODEINVOCATION_H +#define ENGINE_NODEINVOCATION_H + + +#include "proc/state.hpp" +#include "proc/engine/procnode.hpp" +#include "proc/engine/buffhandle.hpp" +#include "proc/engine/bufftable.hpp" + + + + +namespace engine { + + + /** + * Adapter to shield the ProcNode from the actual buffer management, + * allowing the processing function within ProcNode to use logical + * buffer IDs. StateAdapter is created on the stack for each pull() + * call, using setup/wiring data preconfigured by the builder. + * Its job is to provide the actual implementation of the Cache + * push / fetch and recursive downcall to render the source frames. + */ + class StateAdapter + : public State + { + protected: + State& parent_; + State& current_; + + StateAdapter (State& callingProcess) + : parent_ (callingProcess), + current_(callingProcess.getCurrentImplementation()) + { } + + virtual State& getCurrentImplementation () { return current_; } + + + + public: /* === proxying the State interface === */ + + virtual void releaseBuffer (BuffHandle& bh) { current_.releaseBuffer (bh); } + + virtual void is_calculated (BuffHandle const& bh) { current_.is_calculated (bh); } + + virtual BuffHandle fetch (FrameID const& fID) { return current_.fetch (fID); } + + // note: allocateBuffer() is choosen specifically based on the actual node wiring + + }; + + + + + + /** + * Invocation context state. + * A ref to this type is carried through the chain of NEXT::step() functions + * which form the actual invocation sequence. The various operations in this sequence + * access the context via the references in this struct, while also using the inherited + * public State interface. The object instance actually used as Invocation is created + * on the stack and parametrized according to the necessities of the invocation sequence + * actually configured. Initially, this real instance is configured without BuffTable, + * because the invocation may be short-circuited due to Cache hit. Otherwise, when + * the invocation sequence actually prepares to call the process function of this + * ProcNode, a buffer table chunk is allocated by the StateProxy and wired in. + */ + struct Invocation + : StateAdapter + { + WiringDescriptor const& wiring; + const uint outNr; + + BuffTable* buffTab; + + protected: + /** creates a new invocation context state, without BuffTable */ + Invocation (State& callingProcess, WiringDescriptor const& w, uint o) + : StateAdapter(callingProcess), + wiring(w), outNr(o), + buffTab(0) + { } + + const uint nrO() const { return wiring.getNrO(); } + const uint nrI() const { return wiring.getNrI(); } + const uint buffTabSize() const { return nrO()+nrI(); } + + /** setup the link to an externally allocated buffer table */ + void setBuffTab (BuffTable* b) { this->buffTab = b; } + + bool + buffTab_isConsistent () + { + return (buffTab) + && (0 < buffTabSize()) + && (nrO()+nrI() <= buffTabSize()) + && (buffTab->inBuff == &buffTab->outBuff[nrO()] ) + && (buffTab->inHandle == &buffTab->outHandle[nrO()]) + ; + } + + + }; + + + struct AllocBufferFromParent ///< using the parent StateAdapter for buffer allocations + : Invocation + { + AllocBufferFromParent (State& sta, WiringDescriptor const& w, const uint outCh) + : Invocation(sta, w, outCh) {} + + virtual BuffHandle + allocateBuffer (BufferDescriptor const& bd) { return parent_.allocateBuffer(bd); } + }; + + struct AllocBufferFromCache ///< using the global current State, which will delegate to Cache + : Invocation + { + AllocBufferFromCache (State& sta, WiringDescriptor const& w, const uint outCh) + : Invocation(sta, w, outCh) {} + + virtual BuffHandle + allocateBuffer (BufferDescriptor const& bd) { return current_.allocateBuffer(bd); } + }; + + + /** + * The real invocation context state implementation. It is created + * by the NodeWiring (WiringDescriptor) of the processing node which + * is pulled by this invocation, hereby using the internal configuration + * information to guide the selecton of the real call sequence + * + * \par assembling the call sequence implementation + * Each ProcNode#pull() call creates such a StateAdapter subclass on the stack, + * with a concrete type according to the WiringDescriptor of the node to pull. + * This concrete type encodes a calculation Strategy, which is assembled + * as a chain of policy templates on top of OperationBase. For each of the + * possible configuratons we define such a chain (see bottom of nodeoperation.hpp). + * The WiringFactory defined in nodewiring.cpp actually drives the instantiation + * of all those possible combinations. + */ + template + class ActualInvocationProcess + : public BufferProvider + { + public: + ActualInvocationProcess (State& callingProcess, WiringDescriptor const& w, const uint outCh) + : BufferProvider(callingProcess, w, outCh) + { } + + /** contains the details of Cache query and recursive calls + * to the predecessor node(s), eventually followed by the + * ProcNode::process() callback + */ + BuffHandle retrieve () + { + return Strategy::step (*this); + } + }; + + + + +} // namespace engine +#endif diff --git a/src/proc/engine/nodeoperation.hpp b/src/proc/engine/nodeoperation.hpp new file mode 100644 index 000000000..b30c6cbeb --- /dev/null +++ b/src/proc/engine/nodeoperation.hpp @@ -0,0 +1,311 @@ +/* + NODEOPERATION.hpp - Specify how the nodes call each other and how processing is organized + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + +/** @file nodeoperation.hpp + ** Chunks of operation for invoking the rendernodes. + ** This header defines part of the "glue" which holds together the render node network + ** and enables to pull a result frames from the nodes. Especially, the aspect of + ** buffer management and cache query is covered here. Each node has been preconfigured by + ** the builder with a WiringDescriptor and a concrete type of a StateAdapter, including + ** a specific Configuration, because the node can be built to + ** - participate in the Caching or ignore the cache + ** - actually process a result or just pull frames from a source + ** - employ in-Place calculations or use separate in/out buffers + ** Additionally, each node may have a given number of input/output pins, expecting to + ** be provided with buffers holding a specific kind of data. + ** + ** \par composition of the invocation Strategy + ** For each individual ProcNode#pull() call, the WiringAdapter#callDown() builds an Invocation state + ** instance directly on the stack, holding references to the actual buffer pointers and state. Using this + ** StateAdapter, the predecessor nodes are pulled. The way these operations are carried out is encoded + ** in the actual type of Strategy, which is defined at the bottom of this header. Each Strategy is a chain + ** of elementary operations invoking each other (\c NEXT::step(invocation) ). Notably, all those possible + ** configurations are pre-build while compiling (it's a small number below 32 configuration instance). + ** To be able to select the Strategy for each configuration, we need a Factory (ConfigSelector defined in + ** nodewiringconfig). which is actually instantiated and used in nodewiring.cpp, which is the object + ** file holding all those instantiations. + ** + ** @see engine::ProcNode + ** @see engine::Invocation + ** @see engine::State + ** @see engine::NodeFactory + ** @see nodewiringconfig.hpp + ** @see nodewiring.hpp interface for building/wiring the nodes + ** + */ + +#ifndef ENGINE_NODEOPERATION_H +#define ENGINE_NODEOPERATION_H + + +#include "proc/state.hpp" +#include "proc/engine/procnode.hpp" +#include "proc/engine/buffhandle.hpp" +#include "proc/engine/bufftable.hpp" +#include "proc/engine/nodeinvocation.hpp" + +#include "common/meta/util.hpp" +#include "common/meta/configflags.hpp" + + + + +namespace engine { + namespace config { + + + /** + * Collection of functions used to build up the invocation sequence. + */ + class OperationBase + { + typedef lumiera::Yes_t is_defined; + }; + + template + struct QueryCache : NEXT + { + BuffHandle + step (Invocation& ivo) + { + BuffHandle fetched = ivo.fetch ( + this->genFrameID (ivo)); + if (fetched) + return fetched; + else + return NEXT::step (ivo); + } + }; + + + template + struct AllocBufferTable : NEXT + { + BuffHandle + step (Invocation& ivo) + { + BuffTableChunk buffTab (ivo.wiring, ivo.getBuffTableStorage()); + ivo.setBuffTab(&buffTab); + ASSERT (ivo.buffTab); + ASSERT (ivo.buffTab_isConsistent()); + + return NEXT::step (ivo); + } + }; + + + template + struct PullInput : NEXT + { + BuffHandle + step (Invocation& ivo) + { + BuffHandle * inH = ivo.buffTab->inHandle; + BuffHandle::PBuff *inBuff = ivo.buffTab->inBuff; + + for (uint i = 0; i < ivo.nrI(); ++i ) + { + inBuff[i] = + *(inH[i] = this->pullPredecessor(ivo,i)); // invoke predecessor + // now Input #i is ready... + } + return NEXT::step (ivo); // note: passing down a ref to the ProcessInvocation + } + }; + + + template + struct ReadSource : NEXT + { + BuffHandle + step (Invocation& ivo) + { + BuffHandle *inH = ivo.buffTab->inHandle; + BuffHandle *outH = ivo.buffTab->outHandle; + BuffHandle::PBuff *inBuff = ivo.buffTab->inBuff; + BuffHandle::PBuff *outBuff = ivo.buffTab->outBuff; + + ASSERT (ivo.nrO() == ivo.nrI() ); + + for (uint i = 0; i < ivo.nrI(); ++i ) + { + inBuff[i] = outBuff[i] = + *(inH[i] = outH[i] = this->getSource(ivo,i)); + // now Input #i is ready... + } + return NEXT::step (ivo); + } + }; + + + template + struct AllocOutput : NEXT + { + BuffHandle + step (Invocation& ivo) + { + ASSERT (ivo.buffTab); + ASSERT (ivo.nrO() < ivo.buffTabSize()); + BuffHandle *outH = ivo.buffTab->outHandle; + BuffHandle::PBuff *outBuff = ivo.buffTab->outBuff; + + for (uint i = 0; i < ivo.nrO(); ++i ) + { + outBuff[i] = + *(outH[i] = ivo.allocateBuffer (ivo.wiring.out[i].bufferType)); + // now Output buffer for channel #i is available... + } + return NEXT::step (ivo); + } + }; + + + template + struct ProcessData : NEXT + { + BuffHandle + step (Invocation& ivo) + { + ASSERT (ivo.buffTab); + ASSERT (ivo.buffTab_isConsistent()); + ASSERT (this->validateBuffers(ivo)); + + // Invoke our own process() function, + // providing the array of outBuffer+inBuffer ptrs + ivo.wiring.processFunction (ivo.buffTab->outBuff); + + return NEXT::step (ivo); + } + }; + + template + struct FeedCache : NEXT + { + BuffHandle + step (Invocation& ivo) + { + for (uint i = 0; i < ivo.nrO(); ++i ) + { + // declare all Outputs as finished + ivo.is_calculated(ivo.buffTab->outHandle[i]); + } + + return NEXT::step (ivo); + } + }; + + template + struct ReleaseBuffers : NEXT /////////////////TODO: couldn't this be done automatically by BuffTab's dtor?? + { ///////////////// this would require BuffHandle to be a smart ref.... + BuffHandle + step (Invocation& ivo) + { + // all buffers besides the required Output no longer needed + this->releaseBuffers(ivo.buffTab->outHandle, + ivo.buffTabSize(), + ivo.outNr); + + return ivo.buffTab->outHandle[ivo.outNr]; + } + }; + + + + + /* === declare the possible Assembly of these elementary steps === */ + + enum Cases + { + CACHING = 1, + PROCESS, + INPLACE, + + NOT_SET = 0, + NUM_Cases = INPLACE + }; + + + + template + struct SelectBuffProvider; + + template<> struct SelectBuffProvider { typedef AllocBufferFromCache Type; }; + template<> struct SelectBuffProvider { typedef AllocBufferFromParent Type; }; + template<> struct SelectBuffProvider { typedef AllocBufferFromCache Type; }; + template<> struct SelectBuffProvider<> { typedef AllocBufferFromParent Type; }; + + + template + struct Strategy ; + + using lumiera::typelist::Config; + + template + struct Strategy< Config > + : QueryCache< + AllocBufferTable< + PullInput< + AllocOutput< + ProcessData< + FeedCache< + ReleaseBuffers< + OperationBase > > > > > > > + { }; + + template + struct Strategy< Config > + : AllocBufferTable< + PullInput< + AllocOutput< + ProcessData< + ReleaseBuffers< + OperationBase > > > > > + { }; + + template<> + struct Strategy< Config<> > + : AllocBufferTable< + ReadSource< + ReleaseBuffers< + OperationBase > > > + { }; + + template<> + struct Strategy< Config > : Strategy< Config<> > { }; + + template<> + struct Strategy< Config > + : AllocBufferTable< + ReadSource< + AllocOutput< + ProcessData< // wiring_.processFunction is supposed to do just buffer copying here + ReleaseBuffers< + OperationBase > > > > > + { }; + + + + + } // namespace config + +} // namespace engine +#endif diff --git a/src/proc/engine/nodewiring.cpp b/src/proc/engine/nodewiring.cpp new file mode 100644 index 000000000..7d999aa48 --- /dev/null +++ b/src/proc/engine/nodewiring.cpp @@ -0,0 +1,138 @@ +/* + NodeWiring - Implementation of the node network and operation control + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +#include "proc/engine/procnode.hpp" +#include "proc/engine/nodewiring.hpp" +#include "proc/engine/nodeoperation.hpp" +#include "proc/engine/nodewiringconfig.hpp" + +#include "common/meta/typelistutil.hpp" + + +namespace engine { + + namespace config { + + using lumiera::typelist::Flags; + using lumiera::typelist::CombineFlags; + using lumiera::typelist::DefineConfigByFlags; + using lumiera::typelist::Instantiation; + using lumiera::typelist::Apply; + using lumiera::typelist::Filter; + + + typedef Flags::Tuple AllFlags; + + /** build the list of all possible flag combinations */ + typedef CombineFlags AllFlagCombinations; + + /** build a configuration type for each of those flag combinations */ + typedef Apply AllConfigs; + + /** filter those configurations which actually define a wiring strategy */ + typedef Filter::Test> PossibleConfigs; + + } // namespace config + + + + + namespace { // internal: setting up a factory for each required configuration + + using config::ConfigSelector; + + class Alloc {}; ///////////////TODO + + + template + class WiringDescriptorFactory + { + Alloc& alloc_; + + public: + WiringDescriptorFactory(Alloc& a) + : alloc_(a) {} + + WiringDescriptor& + operator() () + { + /////////////////////////////////////////////TODO + + typedef config::Strategy Strategy; + typedef typename config::SelectBuffProvider<>::Type BuffProvider; ////////////////////////TODO: how to extract the required flags from CONF?? + typedef ActualInvocationProcess InvocationStateType; + + typedef NodeWiring Product; + + Product * dummy (0); + return *dummy; + } + }; + + typedef WiringDescriptor& (FunctionType)(void); + + typedef ConfigSelector< WiringDescriptorFactory ///< Factory template + , FunctionType ///< function signature of the Factory + , Alloc& ///< allocator fed to all factories + > WiringSelector; + + + struct WiringFactoryImpl + { + WiringSelector selector; + + WiringFactoryImpl (Alloc& alloc) + : selector(config::PossibleConfigs::List(), alloc) + { } + }; + + } // (END) internals + + + /////////////////////////////TODO: define the ctor + + + /** create and configure a concrete wiring descriptor to tie + * a ProcNode to its predecessor nodes. This includes selecting + * the actual StateProxy type, configuring it out of some operation + * control templates (policy classes). Compiling this operator function + * actually drives the necessary template instantiations for all cases + * encountered while building the node network. + * The created WiringDescriptor object is bulk allocated similar to the ProcNode + * objects for a given segment of the Timeline. It should be further configured + * with the actual predecessor nodes pointers and can then be used to create + * the new processing node to be wired up. + */ + WiringDescriptor& + WiringFactory::operator() (uint nrOut, uint nrIn, bool cache) + { + UNIMPLEMENTED ("build the actual wiring descriptor based on given operation options"); + +// Bits config (FlagInfo::CODE); + size_t config = 13; /////////////////////////////////////////TODO +// return pImpl_->selector[config](); + } + // BlockAlloc > > >::fabricate(); + + +} // namespace engine diff --git a/src/proc/engine/nodewiring.hpp b/src/proc/engine/nodewiring.hpp new file mode 100644 index 000000000..442ca4297 --- /dev/null +++ b/src/proc/engine/nodewiring.hpp @@ -0,0 +1,90 @@ +/* + NODEWIRING.hpp - Implementation of the node network and operation control + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef ENGINE_NODEWIRING_H +#define ENGINE_NODEWIRING_H + + +#include "proc/engine/procnode.hpp" + +#include +#include + + + +namespace engine { + + + class WiringFactory; + + namespace { class WiringFactoryImpl; } + + + /** + * Actual implementation of the link between nodes, + * also acting as "track switch" for the execution path + * choosen while operating the node network for rendering. + * @param STATE Invocation state object controlling the + * behaviour of callDown() while rendering. + * @see StateAdapter + * @see NodeFactory + */ + template + class NodeWiring + : public WiringDescriptor + { + const uint siz_; + const uint nrO_; + + friend class WiringFactory; + + public: + virtual uint getNrI() const { return siz_ - nrO_; } + virtual uint getNrO() const { return nrO_; } + + + protected: + virtual BuffHandle + callDown (State& currentProcess, uint requiredOutputNr) const + { + STATE thisStep (currentProcess, *this); + return thisStep.retrieve (requiredOutputNr); // fetch or calculate results + } + + }; + + + + class WiringFactory + { + boost::scoped_ptr pImpl_; + + public: + WiringDescriptor& + operator() (uint nrOut, uint nrIn, bool cache); + }; + + + +} // namespace engine +#endif diff --git a/src/proc/engine/nodewiringconfig.hpp b/src/proc/engine/nodewiringconfig.hpp new file mode 100644 index 000000000..aac1ff7a1 --- /dev/null +++ b/src/proc/engine/nodewiringconfig.hpp @@ -0,0 +1,180 @@ +/* + NODEWIRINGCONFIG.hpp - Helper for representing and selecting the wiring case + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ +/** @file nodewiringconfig.hpp + ** Sometimes we need to coose a different implementation for dealing with + ** some special cases. While for simple cases, just testing a flag or using a + ** switch statement will do the job, matters get more difficult when we have to + ** employ a completely different execution path for each of the different cases, + ** while using a set of common building blocks. + ** \par + ** In the Lumiera render engine, right on the critical path, we need some glue code + ** for invoking the predecessor nodes when pulling a given processing node. The actual + ** sequence is quite dependant on the specific situation each node is wired up, regarding + ** buffer allocation, cache querying and the possible support for GPU processing and + ** render farms. The solution is to define specialisations of a Strategy template + ** using the specific configuration as template argument. Based on these, we can + ** create a collection of factories, which in turn will build the internal wiring + ** for the individual ProcNode instances in accordance to the situation determined + ** for this node, expressed as a set of flags. As a net result, each node has an + ** indivudual configuration (as opposed to creating a lot of hand-written individual + ** ProcNode subclasses), but parts of this configuration assembly is done already at + ** compile time, allowing for additional checks by typing and for possible optimisation. + ** + ** @see proc::engine::config::Strategy + ** @see nodewiring.hpp + ** @see configflags.hpp + ** + */ +#ifndef ENGINE_NODEWIRINGCONFIG_H +#define ENGINE_NODEWIRINGCONFIG_H + + +#include "common/util.hpp" +#include "common/meta/configflags.hpp" + +#include +#include +#include + + +namespace engine { + namespace config { + + using lumiera::typelist::FlagInfo; + using util::contains; + + using lumiera::typelist::CONFIG_FLAGS_MAX; + + + /** + * Helper for fabricating ProcNode Wiring configurations. + * This object builds a table of factories, holding one factory + * for each possible node configuration. Provided with the desired + * configuration encoded as bits, the related factory can be invoked, + * thus producing a product object for the given configuration. + * + * \par implementation notes + * The actual factory class is templated, so it will be defined + * at the use site of ConfigSelector. Moreover, this factory + * usually expects an ctor argument, which will be fed through + * when creating the ConfigSelector instance. This is one of + * the reasons why we go through all these complicated factory + * building: this ctor argument usually brings in a reference + * to the actual memory allocator. Thus we have to rebuild the + * ConfigSelector each time we switch and rebuild the ProcNode + * factories, which in turn happens each time we use a new + * bulk allocation memory block -- typically for each separate + * segment of the Timeline and processing node graph. + * + * Now the selection of the possible flag configurations, for which + * Factory instances are created in the table, is governed by the + * type parameter of the ConfigSelector ctor. This type parameter + * needs to be a Typelist of Typelists, each representing a flag + * configuration. The intention is to to drive this selection by + * the use of template metaprogramming for extracting all + * currently defined StateProxy object configurations. + * @todo as the facories live only within the enclosed table (map) + * we could allocate them in-place. Unfortunately this is + * non-trivial, because the stl containers employ + * value semantics and thus do a copy even on insert. + * Thus, for now we use a shared_ptr to hold the factory + * heap allocated. + */ + template< template class Factory + , typename FUNC ///< common function type of all Factory instances + , typename PAR ///< ctor parameter of the Factories + > + class ConfigSelector + { + typedef boost::function FacFunction; + + template + struct FactoryHolder + : private FAC, + public FacFunction + { + FactoryHolder(PAR p) + : FAC(p), + FacFunction( static_cast(*this)) + { } + }; + + + typedef std::tr1::shared_ptr PFunc; + typedef std::map ConfigTable; + + ConfigTable possibleConfig_; ///< Table of factories + + /** Helper: a visitor usable with FlagInfo */ + struct FactoryTableBuilder + { + PAR ctor_param_; + ConfigTable& factories_; + + FactoryTableBuilder (ConfigTable& tab, PAR p) + : ctor_param_(p), + factories_(tab) { } + + + /* === visitation interface === */ + + typedef void Ret; + + template + void + visit (size_t code) + { + PFunc pFactory (new FactoryHolder > (ctor_param_)); + factories_[code] = pFactory; + } + + void done() {} + }; + + public: + template + ConfigSelector(CONFS const&, PAR factory_ctor_param) + { + FactoryTableBuilder buildTable(this->possibleConfig_, + factory_ctor_param ); + // store a new Factory instance + // for each possible Flag-Configuration + FlagInfo::accept (buildTable); + } + + FacFunction& + operator[] (size_t configFlags) ///< retrieve the factory corresponding to the given config + { + if (contains (possibleConfig_, configFlags)) + return *possibleConfig_[configFlags]; + else + throw lumiera::error::Invalid("ConfigSelector: No preconfigured factory for config-bits=" + +std::bitset(configFlags).to_string()); + } + }; + + + + } // namespace config + +} // namespace engine +#endif diff --git a/src/proc/engine/processor.cpp b/src/proc/engine/processor.cpp index c8a228845..38ed34c5d 100644 --- a/src/proc/engine/processor.cpp +++ b/src/proc/engine/processor.cpp @@ -22,8 +22,7 @@ #include "proc/engine/processor.hpp" -#include "proc/engine/exitnode.hpp" -#include "proc/stateproxy.hpp" +#include "proc/state.hpp" namespace engine { diff --git a/src/proc/engine/processor.hpp b/src/proc/engine/processor.hpp index 164fa8bfa..3f0890c93 100644 --- a/src/proc/engine/processor.hpp +++ b/src/proc/engine/processor.hpp @@ -25,7 +25,7 @@ #define ENGINE_PROCESSOR_H #include "proc/lumiera.hpp" -#include "proc/stateproxy.hpp" +#include "proc/state.hpp" diff --git a/src/proc/engine/procnode.cpp b/src/proc/engine/procnode.cpp index 48e33c498..984c4dece 100644 --- a/src/proc/engine/procnode.cpp +++ b/src/proc/engine/procnode.cpp @@ -22,12 +22,14 @@ #include "proc/engine/procnode.hpp" +#include "proc/engine/nodefactory.hpp" -namespace engine - { +namespace engine { - /** */ + /** Storage for the (single, static) ProcNode factory object. + */ + NodeFactory ProcNode::create; } // namespace engine diff --git a/src/proc/engine/procnode.hpp b/src/proc/engine/procnode.hpp index ae210f96b..343c6a6e8 100644 --- a/src/proc/engine/procnode.hpp +++ b/src/proc/engine/procnode.hpp @@ -20,39 +20,137 @@ */ +/** @file procnode.hpp + ** Interface to the processing nodes and the render nodes network. + ** + ** Actually, there are three different interfaces to consider + ** - the ProcNode#pull is the invocation interface. It is call-style (easily callable by C) + ** - the builder interface, comprised by the NodeFactory and the WiringFactory. It's C++ (using templates) + ** - the actual processing function is supposed to be a C function; it uses a set of C functions + ** for accessing the frame buffers with the data to be processed. + ** + ** By using the builder interface, concrete node and wiring descriptor classes are created, + ** based on some templates. These concrete classes form the "glue" to tie the node network + ** together and contain much of the operation beahviour in a hard wired fashion. + ** + ** @see nodefactory.hpp + ** @see operationpoint.hpp + */ #ifndef ENGINE_PROCNODE_H #define ENGINE_PROCNODE_H -#include +#include "pre.hpp" +#include "proc/lumiera.hpp" +#include "proc/state.hpp" #include "proc/mobject/parameter.hpp" - -using std::vector; +#include -namespace engine - { - +namespace engine { + using std::vector; + using proc_interface::State; + + class ProcNode; + class NodeFactory; + + typedef ProcNode* PNode; + + template + struct RefArray + { + virtual E const& operator[] (uint i) const =0; + virtual ~RefArray() {} + }; + + /** + * Interface: Description of the input and output ports, + * processing function and predecessor nodes for a given ProcNode. + */ + class WiringDescriptor + { + public: + virtual ~WiringDescriptor() {} + + virtual uint getNrI() const =0; ///////////TODO: indeed need a virtual function?? + virtual uint getNrO() const =0; + + RefArray& out; + RefArray& in; + + typedef void (ProcFunc) (BuffHandle::PBuff, uint); + + ProcFunc* processFunction; + + protected: + WiringDescriptor (RefArray& o, + RefArray& i, + ProcFunc pFunc) + : out(o), in(i), + processFunction(pFunc) + { } + + /** the wiring-dependent part of the node operation. + * Includes the creation of a one-way state object on the stack + * holding the actual buffer pointers and issuing the recrusive pull() calls + * @see NodeWiring#callDown default implementation + */ + virtual BuffHandle callDown (State& currentProcess, uint requiredOutputNr) const =0; + + friend class ProcNode; + + }; + + + + /** * Key abstraction of the Render Engine: A Data processing Node */ class ProcNode { - protected: - typedef mobject::Parameter Param; - - /** The predecessor in a processing pipeline. - * I.e. a source to get data to be processed - */ - ProcNode * datasrc; - + typedef mobject::Parameter Param; //////TODO: just a placeholder for automation as of 6/2008 vector params; - + + const WiringDescriptor& wiringConfig_; + + protected: + ProcNode (WiringDescriptor const& wd) + : wiringConfig_(wd) + { } + + virtual ~ProcNode() {}; + + friend class NodeFactory; + + + + public: + static NodeFactory create; ///////TODO: really? probably we'll rather have a NodeFactory object in the builder... + + /** Engine Core operation: render and pull output from this node. + * On return, currentProcess will hold onto output buffer(s) + * containing the calculated result frames. In case this node + * calculates a multi channel output, only one channel can be + * retrieved by such a \c pull() call, but you can expect data + * of the other channels to be processed and fed to cache. + * @param currentProcess the current processing state for + * managing buffers and accessing current parameter values + * @param requiredOutputNr the output channel requested (in case + * this node delivers more than one output channel) + * @return handle to the buffer containing the calculated result. + */ + BuffHandle + pull (State& currentProcess, uint requiredOutputNr=0) const + { + return this->wiringConfig_.callDown (currentProcess, requiredOutputNr); + } + }; - + } // namespace engine #endif diff --git a/src/proc/engine/projector.hpp b/src/proc/engine/projector.hpp index 0908eec38..4e03c4cc2 100644 --- a/src/proc/engine/projector.hpp +++ b/src/proc/engine/projector.hpp @@ -37,7 +37,7 @@ namespace engine */ class Projector : public Trafo { - //////////// + ////////////TODO adapt ctor }; diff --git a/src/proc/engine/source.hpp b/src/proc/engine/source.hpp index 37af97841..3573f3e0b 100644 --- a/src/proc/engine/source.hpp +++ b/src/proc/engine/source.hpp @@ -40,7 +40,9 @@ namespace engine */ class Source : public ProcNode { - /////////////////TODO + Source (WiringDescriptor const& wd) + : ProcNode(wd) + { } }; diff --git a/src/proc/stateproxy.cpp b/src/proc/engine/stateproxy.cpp similarity index 81% rename from src/proc/stateproxy.cpp rename to src/proc/engine/stateproxy.cpp index f4125a41e..6e2566d3e 100644 --- a/src/proc/stateproxy.cpp +++ b/src/proc/engine/stateproxy.cpp @@ -1,5 +1,5 @@ /* - StateProxy - Key Interface representing a render process and encapsulating state + StateProxy - Encapsulation of the state corresponding to a render calculation Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,14 +21,12 @@ * *****************************************************/ -#include "proc/stateproxy.hpp" -#include "proc/frame.hpp" +#include "proc/engine/stateproxy.hpp" -namespace proc_interface - { +namespace engine { /** */ -} // namespace proc_interface +} // namespace engine diff --git a/src/proc/stateproxy.hpp b/src/proc/engine/stateproxy.hpp similarity index 73% rename from src/proc/stateproxy.hpp rename to src/proc/engine/stateproxy.hpp index 7c338bd1d..ff7d107d3 100644 --- a/src/proc/stateproxy.hpp +++ b/src/proc/engine/stateproxy.hpp @@ -1,5 +1,5 @@ /* - STATEPROXY.hpp - Key Interface representing a render process and encapsulating state + STATEPROXY.hpp - Encapsulation of the state corresponding to a render calculation Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,25 +21,26 @@ */ -#ifndef PROC_INTERFACE_STATEPROXY_H -#define PROC_INTERFACE_STATEPROXY_H - -#include "proc/frame.hpp" +#ifndef ENGINE_STATEPROXY_H +#define ENGINE_STATEPROXY_H +#include "proc/state.hpp" + + +namespace engine { -namespace proc_interface - { class StateProxy + : public proc_interface::State { protected: - Frame * currFrame; - + virtual State& getCurrentImplementation () { return *this; } + }; -} // namespace proc_interface +} // namespace engine #endif diff --git a/src/proc/engine/trafo.hpp b/src/proc/engine/trafo.hpp index 8d2155661..166154674 100644 --- a/src/proc/engine/trafo.hpp +++ b/src/proc/engine/trafo.hpp @@ -42,9 +42,25 @@ namespace engine */ class Trafo : public ProcNode { - /////////// + protected: + Trafo (WiringDescriptor const& wd) + : ProcNode(wd) + { } + + friend class NodeFactory; + + + + /** do the actual calculations. + * @internal dispatch to implementation. + * Client code should use #render() + * @todo obviously we need a parameter!!! + */ + virtual void process() = 0; }; + typedef Trafo* PTrafo; ///< @todo handle ProcNode by pointer or by shared-ptr?? + } // namespace engine diff --git a/src/proc/engine/vframe.cpp b/src/proc/engine/vframe.cpp deleted file mode 100644 index 180faca70..000000000 --- a/src/proc/engine/vframe.cpp +++ /dev/null @@ -1,33 +0,0 @@ -/* - VFrame - a buffer holding a Video frame for the render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/vframe.hpp" - -namespace engine - { - - /** */ - - - -} // namespace engine diff --git a/src/proc/engine/vframe.hpp b/src/proc/engine/vframe.hpp deleted file mode 100644 index 6b1e8153b..000000000 --- a/src/proc/engine/vframe.hpp +++ /dev/null @@ -1,41 +0,0 @@ -/* - VFRAME.hpp - a buffer holding a Video frame for the render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_VFRAME_H -#define ENGINE_VFRAME_H - -#include "proc/frame.hpp" - - - -namespace engine - { - - - class VFrame : public proc_interface::Frame - { - /////////////////////// - }; - -} // namespace engine -#endif diff --git a/src/proc/engine/vrender.cpp b/src/proc/engine/vrender.cpp deleted file mode 100644 index 2bed41099..000000000 --- a/src/proc/engine/vrender.cpp +++ /dev/null @@ -1,33 +0,0 @@ -/* - VRender - Representation of a Video render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/engine/vrender.hpp" - -namespace engine - { - - /** */ - - - - } // namespace engine diff --git a/src/proc/engine/vrender.hpp b/src/proc/engine/vrender.hpp deleted file mode 100644 index c6a34bda2..000000000 --- a/src/proc/engine/vrender.hpp +++ /dev/null @@ -1,47 +0,0 @@ -/* - VRENDER.hpp - Representation of a Video render process - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -*/ - - -#ifndef ENGINE_VRENDER_H -#define ENGINE_VRENDER_H - -#include "proc/stateproxy.hpp" - - - -namespace engine - { - - - /** - * Representation of a Video render process. - * (Encapsulates the video buffers for the actual calculations) - */ - class VRender : public proc_interface::StateProxy - { - ///////////// - }; - - - -} // namespace engine -#endif diff --git a/src/proc/mobject/builder/applicablebuildertargettypes.hpp b/src/proc/mobject/builder/applicablebuildertargettypes.hpp index e51fa1251..b02fb9d45 100644 --- a/src/proc/mobject/builder/applicablebuildertargettypes.hpp +++ b/src/proc/mobject/builder/applicablebuildertargettypes.hpp @@ -55,7 +55,7 @@ namespace mobject { * common selection of types to be handled by any such builder tool. * The actual BuilderTool impl should inherit from this template by * feeding back its type (CRTP), this causes a dispatcher table entry - * be generated for this concrete BuilderTool implementation. + * to be generated for this concrete BuilderTool implementation. */ template struct ApplicableBuilderTargetTypes diff --git a/src/proc/mobject/builder/mould.hpp b/src/proc/mobject/builder/mould.hpp new file mode 100644 index 000000000..be29f2b21 --- /dev/null +++ b/src/proc/mobject/builder/mould.hpp @@ -0,0 +1,87 @@ +/* + MOULD.hpp - builder tool kit for the basic building situations + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef MOBJECT_BUILDER_MOULD_H +#define MOBJECT_BUILDER_MOULD_H + + +#include "proc/asset/procpatt.hpp" +#include "proc/mobject/builder/operationpoint.hpp" + +#include + +namespace mobject { + namespace builder { + + using std::vector; + using asset::PProcPatt; + using lumiera::Symbol; + + + /** + * Interface: a workbench-like tool used by the builder + * for wiring up a specific building situation, followed by + * the application/execution of a single building step. Mould is + * conceived as the passive part, while usually the ProcPatt plays + * the role of the active counterpart. By means of the Mould interface, + * the specifics of a build situation are abstracted away, thus allowing + * the processing pattern to be defined as working on symbolic locations. + * Most commonly this is "current", denoting the render node just being built. + *
    • PipeMould supports attaching an effect to a pipe
      • + *
    • combining pipes via a transition is done by a CombiningMould
      • + *
    • a SourceChainMould allows to start out from a source reader and build a clip
      • + *
    • wiring general connections is supported by the WiringMould
      • + *
    + * @see ToolFactory + * @see NodeCreatorTool + */ + class Mould + { + public: + vector operate (); + + OperationPoint& getLocation (Symbol locationID); + }; + + + class PipeMould : public Mould + { + }; + + class CombiningMould : public Mould + { + }; + + class SourceChainMould : public Mould + { + }; + + class WiringMould : public Mould + { + }; + + + } // namespace mobject::builder + +} // namespace mobject +#endif diff --git a/src/proc/mobject/builder/operationpoint.hpp b/src/proc/mobject/builder/operationpoint.hpp new file mode 100644 index 000000000..f72d9c711 --- /dev/null +++ b/src/proc/mobject/builder/operationpoint.hpp @@ -0,0 +1,73 @@ +/* + OPERATIONPOINT.hpp - abstraction representing the point where to apply a build instruction + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef MOBJECT_BUILDER_OPERATIONPOINT_H +#define MOBJECT_BUILDER_OPERATIONPOINT_H + +#include "proc/engine/procnode.hpp" +#include "common/query.hpp" + +#include +#include + + +namespace mobject { + namespace builder { + + using std::vector; + using std::string; + + /** + * A point in the render node network under construction. + * By means of this unspecific reference, a ProcPatt is able + * to deal with this location and to execute a single elementary + * building operation denoted by a BuildInstruct at this point. + * Usually, the actual point is retrieved from a Mould + */ + class OperationPoint + { + typedef engine::PNode PNode; + + vector refPoint_; + const string streamID_; + + public: + /** create node(s) corresponding to the given Processor-Asset + * and wire them as a successor to this OperationPoint; then + * move this point to refer to the resulting new exit node(s) + */ + void attach (asset::PProc const&); + + /** connect the output this OperationPoint referes such as to + * connect or combine with the input of the already existing + * nodes accessible via the target OperationPoint. + */ + void join (OperationPoint& target); + }; + + + + } // namespace mobject::builder + +} // namespace mobject +#endif diff --git a/src/proc/mobject/builder/toolfactory.hpp b/src/proc/mobject/builder/toolfactory.hpp index 2061b4fd2..c796d5c9e 100644 --- a/src/proc/mobject/builder/toolfactory.hpp +++ b/src/proc/mobject/builder/toolfactory.hpp @@ -25,6 +25,7 @@ #define MOBJECT_BUILDER_TOOLFACTORY_H #include "proc/mobject/builder/buildertool.hpp" +#include "proc/mobject/builder/mould.hpp" @@ -34,6 +35,12 @@ namespace mobject { + /** + * provides the builder with the necessary, preconfigured tools. + * Dedicated to a single build process, it holds the internal state + * of this process and thus serves to coordinate and link together all + * the individual parts fabricated by using the various tools. + */ class ToolFactory { public: diff --git a/src/proc/mobject/controller/renderstate.cpp b/src/proc/mobject/controller/renderstate.cpp deleted file mode 100644 index 98ca2ccd1..000000000 --- a/src/proc/mobject/controller/renderstate.cpp +++ /dev/null @@ -1,44 +0,0 @@ -/* - RenderState - renderengine state manager - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - -* *****************************************************/ - - -#include "proc/mobject/controller/renderstate.hpp" - - -namespace mobject - { - namespace controller - { - - - - StateProxy& - RenderState::getStateProxy () - { - //////////////TODO - } - - - - } // namespace mobject::controller - -} // namespace mobject diff --git a/src/proc/mobject/controller/renderstate.hpp b/src/proc/mobject/controller/renderstate.hpp index c547772ea..833e2d347 100644 --- a/src/proc/mobject/controller/renderstate.hpp +++ b/src/proc/mobject/controller/renderstate.hpp @@ -24,7 +24,7 @@ #ifndef MOBJECT_CONTROLLER_RENDERSTATE_H #define MOBJECT_CONTROLLER_RENDERSTATE_H -#include "proc/stateproxy.hpp" +#include "proc/state.hpp" @@ -33,7 +33,7 @@ namespace mobject namespace controller { - typedef proc_interface::StateProxy StateProxy; + typedef proc_interface::State State; /** @@ -42,11 +42,12 @@ namespace mobject * The provided StateProxy serves to hold any mutalbe state used * in the render process, so the rest of the render engine * can be stateless. + * @todo probably the state management will work different (6/08) */ class RenderState { public: - StateProxy& getStateProxy () ; + State& getRenderProcess () ; }; diff --git a/src/proc/mobject/session/mobjectfactory.hpp b/src/proc/mobject/session/mobjectfactory.hpp index 427385194..e1a7a5695 100644 --- a/src/proc/mobject/session/mobjectfactory.hpp +++ b/src/proc/mobject/session/mobjectfactory.hpp @@ -28,8 +28,8 @@ -namespace asset - { +namespace asset { + class Clip; class Media; class Track; @@ -37,10 +37,9 @@ namespace asset } -namespace mobject - { - namespace session - { +namespace mobject { + namespace session { + class Clip; class Track; class Effect; @@ -57,10 +56,10 @@ namespace mobject public: - Placement operator() (const asset::Clip&, const asset::Media&); - Placement operator() (const asset::Clip&, vector); + Placement operator() (asset::Clip const&, asset::Media const&); + Placement operator() (asset::Clip const&, vector); Placement operator() (PTrackAsset&); - Placement operator() (const asset::Effect&); + Placement operator() (asset::Effect const&); }; diff --git a/src/proc/frame.cpp b/src/proc/state.cpp similarity index 80% rename from src/proc/frame.cpp rename to src/proc/state.cpp index 46ad06950..fa9f32dc3 100644 --- a/src/proc/frame.cpp +++ b/src/proc/state.cpp @@ -1,5 +1,5 @@ /* - Frame - Key Abstraction: render process and buffer holding frame data. + State - Key Interface representing a render process and encapsulating state Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,11 +21,12 @@ * *****************************************************/ -#include "proc/frame.hpp" +#include "proc/state.hpp" namespace proc_interface { + ////////////////////////////////TODO: State is a high -level interface, so can we get rid of this implementation file? /** */ diff --git a/src/proc/state.hpp b/src/proc/state.hpp new file mode 100644 index 000000000..cd98a39b8 --- /dev/null +++ b/src/proc/state.hpp @@ -0,0 +1,101 @@ +/* + STATE.hpp - Key Interface representing a render process and encapsulating state + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + + +#ifndef PROC_INTERFACE_STATE_H +#define PROC_INTERFACE_STATE_H + + +#include "pre.hpp" + +#include "proc/lumiera.hpp" +#include "common/frameid.hpp" +#include "proc/engine/buffhandle.hpp" + +#include + + +namespace engine { + + using lumiera::FrameID; + + class StateAdapter; + class BuffTableStorage; + + class State + { + protected: + virtual ~State() {}; + + /** resolves to the State object currently "in charge". + * Intended as a performance shortcut to avoid calling + * up through a chain of virtual functions when deep down + * in chained ProcNode::pull() calls. This allows derived + * classes to proxy the state inteface. + */ + virtual State& getCurrentImplementation () =0; + + friend class engine::StateAdapter; + + public: + /** allocate a new writable buffer with type and size according to + * the BufferDescriptor. The actual provider of this buffer depends + * on the State implementation; it could be a temporary, located in + * the cache, used for feeding calculated frames over a network, etc. + * @return a BuffHandle encapsulating the information necessary to get + * at the actual buffer adress and for releasing the buffer. + */ + virtual BuffHandle allocateBuffer (BufferDescriptor const&) =0; + + /** resign control of the buffer denoted by the handle */ + virtual void releaseBuffer (BuffHandle&) =0; + + /** declare the data contained in the Buffer to be ready. + * The caller is required to restrain itself from modifying the data + * afterwards, as this buffer now can be used (readonly) by other + * calculation processes in parallel. + */ + virtual void is_calculated (BuffHandle const&) =0; + + /** try to fetch an existing buffer containing the denoted frame from + * a cache or similar backing system (e.g. peer over the network). + * @return either a handle to a readonly buffer, or a null handle + * @note the client is resposible for not modifying the provided data + */ + virtual BuffHandle fetch (FrameID const&) =0; + + /** necessary for creating a local BuffTableChunk */ + virtual BuffTableStorage& getBuffTableStorage() =0; + + }; + +} // namespace engine + + + +namespace proc_interface { + + using engine::State; + + +} // namespace proc_interface +#endif diff --git a/src/tool/try.cpp b/src/tool/try.cpp index 85a3286a0..3f51bcaf6 100644 --- a/src/tool/try.cpp +++ b/src/tool/try.cpp @@ -10,234 +10,111 @@ // 4/08 - comparison operators on shared_ptr // 4/08 - conversions on the value_type used for boost::any // 5/08 - how to guard a downcasting access, so it is compiled in only if the involved types are convertible +// 7/08 - combining partial specialisation and subclasses #include #include #include - -#include -#include -#include -#include -#include -#include - +#include using std::string; using std::cout; using std::ostream; +using boost::format; - using boost::remove_pointer; - using boost::remove_reference; - using boost::is_convertible; - using boost::is_polymorphic; - using boost::is_base_of; - using boost::enable_if; - - template - struct can_cast : boost::false_type {}; - - template - struct can_cast { enum { value = is_base_of::value };}; - - template - struct can_cast { enum { value = is_base_of::value };}; - - template - struct can_cast { enum { value = is_base_of::value };}; - - - template - struct has_RTTI - { - typedef typename remove_pointer< - typename remove_reference::type>::type TPlain; +#include +using boost::enable_if; +#include +using boost::is_base_of; +#include +#include + + +#include "common/meta/generator.hpp" +using lumiera::typelist::NullType; +using lumiera::typelist::Node; +using lumiera::typelist::Types; + + + namespace { + + boost::format fmt ("<%2i>"); + + /** constant-wrapper type for debugging purposes, + * usable for generating lists of distinghishable types + */ + template + struct Num + { + enum{ VAL=I }; + static string str () { return boost::str (fmt % I); } + Num() + { + cout << Num::str(); + } + }; + - enum { value = is_polymorphic::value }; - }; - template - struct use_dynamic_downcast + template class _CandidateTemplate_> + class Instantiation { - enum { value = can_cast::value - && has_RTTI::value - && has_RTTI::value - }; - }; - - template - struct use_static_downcast - { - enum { value = can_cast::value - && ( !has_RTTI::value - || !has_RTTI::value - ) - }; - }; - - template - struct use_conversion - { - enum { value = is_convertible::value - && !( use_static_downcast::value - ||use_dynamic_downcast::value - ) - }; - }; - - - template - struct EmptyVal - { - static X create() + template + struct If_possibleArgument : _CandidateTemplate_ { - cout << " NULL() " << __PRETTY_FUNCTION__ <<"\n"; - return X(); - } - }; - template - struct EmptyVal - { - static X*& create() - { - cout << " NULL & " << __PRETTY_FUNCTION__ <<"\n"; - static X* null(0); - return null; - } - }; - - - template - struct NullAccessor - { - typedef RET Ret; + typedef void Type; + }; + + public: + + template + struct Test + : boost::false_type {}; + + template + struct Test::Type > + : boost::true_type {}; - static RET access (...) { return ifEmpty(); } - static RET ifEmpty () { return EmptyVal::create(); } - }; - - template - struct AccessCasted : NullAccessor - { - using NullAccessor::access; - - template - static typename enable_if< use_dynamic_downcast, TAR>::type - access (ELM& elem) - { - cout << " dynamic " << __PRETTY_FUNCTION__ <<"\n"; - return dynamic_cast (elem); - } - - template - static typename enable_if< use_static_downcast, TAR>::type - access (ELM& elem) - { - cout << " static " << __PRETTY_FUNCTION__ <<"\n"; - return static_cast (elem); - } - - template - static typename enable_if< use_conversion, TAR>::type - access (ELM& elem) - { - cout << " convert " << __PRETTY_FUNCTION__ <<"\n"; - return elem; - } - }; + + } + + struct Boing { typedef boost::true_type is_defined; }; + + template struct Zoing ; + + template<> struct Zoing<2> : Boing { enum{wau = 2}; }; + template<> struct Zoing<5> : Boing { enum{wau = 5}; }; - - - -struct B {}; -struct D : B {}; - -struct E : D + typedef char yes_type; + struct no_type { - virtual ~E() {}; + char padding[8]; }; -struct F : E {}; + template + yes_type check(typename U::is_defined *); + template + no_type check(...); -ostream& operator<< (ostream& s, const B& b) { return s << "B{} adr="<<&b; } -ostream& operator<< (ostream& s, const D& d) { return s << "D{} adr="<<&d; } -ostream& operator<< (ostream& s, const E& e) { return s << "E{} adr="<<&e; } -ostream& operator<< (ostream& s, const F& f) { return s << "F{} adr="<<&f; } - + int main (int argc, char* argv[]) { NOBUG_INIT; - D d; - D* pD =&d; - B* pB =pD; - D& rD = *pD; - B& rB = *pB; - - D*& rpD = pD; - B*& rpB = pB; - - F f; - E& rE = f; - E* pE = &f; - D* pDE = pE; - - cout << "is_base_of = " << is_base_of::value << "\n"; - cout << "is_base_of = " << is_base_of::value << "\n"; - cout << "is_base_of = " << is_base_of::value << "\n"; - - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - - cout << "can_cast = " << can_cast::value << "\n"; - cout << "can_cast = " << can_cast::value << "\n"; - - cout << "has_RTTI = " << has_RTTI::value << "\n"; - cout << "has_RTTI = " << has_RTTI::value << "\n"; - cout << "has_RTTI = " << has_RTTI::value << "\n"; + typedef Zoing<2> Z2; + typedef Zoing<3> Z3; + typedef Zoing<5> Z5; + + cout << sizeof(check(0)) << " / " + << sizeof(check(0)) << " / " + << sizeof(check(0)) ; - cout << "use_dynamic_downcast = " << use_dynamic_downcast::value << "\n"; - cout << "use_static_downcast = " << use_static_downcast::value << "\n"; - cout << "use_conversion = " << use_conversion::value << "\n"; - - cout << "use_static_downcast = " << use_static_downcast::value << "\n"; - cout << "use_static_downcast = " << use_static_downcast::value << "\n"; - cout << "use_dynamic_downcast = " << use_dynamic_downcast::value << "\n"; - - - cout << "Access(D as D&) --->" << AccessCasted::access(d) << "\n"; - cout << "Access(D& as D&) --->" << AccessCasted::access(rD) << "\n"; - cout << "Access(B& as D&) --->" << AccessCasted::access(rB) << "\n"; - cout << "Access(D* as D*) --->" << AccessCasted::access(pD) << "\n"; - cout << "Access(B* as D*) --->" << AccessCasted::access(pB) << "\n"; - cout << "Access(D*& as D*&) --->" << AccessCasted::access(rpD) << "\n"; - cout << "Access(B*& as D*&) --->" << AccessCasted::access(rpB) << "\n"; - - cout << "Access(D as B&) --->" << AccessCasted::access(d) << "\n"; - cout << "Access(D& as B&) --->" << AccessCasted::access(rD) << "\n"; - cout << "Access(B& as B&) --->" << AccessCasted::access(rB) << "\n"; - cout << "Access(D* as B*) --->" << AccessCasted::access(pD) << "\n"; - cout << "Access(B* as B*) --->" << AccessCasted::access(pB) << "\n"; - cout << "Access(D*& as B*&) --->" << AccessCasted::access(rpD) << "\n"; - cout << "Access(B*& as B*&) --->" << AccessCasted::access(rpB) << "\n"; - - cout << "Access(D as E&) --->" << AccessCasted::access(d) << "\n"; - cout << "Access(E& as F&) --->" << AccessCasted::access(rE) << "\n"; - cout << "Access(D(E)* as E*) --->" << AccessCasted::access(pDE) << "\n"; - cout << "Access(D(E)* as F*) --->" << AccessCasted::access(pDE) << "\n"; - cout << "Access(E* as F*) --->" << AccessCasted::access(pE) << "\n"; - cout << "\ngulp\n"; diff --git a/tests/50components.tests b/tests/50components.tests index ae15f37c3..417b094ab 100644 --- a/tests/50components.tests +++ b/tests/50components.tests @@ -50,6 +50,109 @@ out: Standard Cmdlineformat:one two END +TEST "ConfigFlags_test" ConfigFlags_test <- +out: Conf2 :-<2>- +out: Conf3 :-<3>- +out: Conf4 :-<2>-<4>- +out: AllFlags :-<1>-<2>-<3>-<4>- +out: __________________________ +out: __________________________ check_flags() +out: Flags1 :-<2>-<4>- +out: Flags2 :-<2>-<4>- +out: SimpleConfig_defined_by_Typelist :-<1>- +out: AnotherConfig_defined_by_Typelist :-<1>-<2>-<3>-<4>- +out: __________________________ +out: __________________________ check_instantiation() +out: defined Conf0? ---> 0 +out: defined Conf1? ---> 1 +out: defined Conf2? ---> 1 +out: defined Conf3? ---> 1 +out: defined Conf4? ---> 1 +out: defined Trash? ---> 0 +out: __________________________ +out: __________________________ check_filter() +out: SomeFlagsets : +out: +---<1>-<3>-+ +out: +---<2>-<4>-+- +out: Configs_defined_by_Flagsets : +out: +-Conf-[-<1>-<3>-] +out: +-Conf-[-<2>-<4>-]- +out: Filter_possible_Configs : +out: +-Conf-[-<2>-<4>-]- +out: AllFlagCombinations : +out: +---<1>-<2>-<3>-<4>-<·>-+ +out: +---<1>-<2>-<3>-<·>-+ +out: +---<1>-<2>-<4>-<·>-+ +out: +---<1>-<2>-<·>-+ +out: +---<1>-<3>-<4>-<·>-+ +out: +---<1>-<3>-<·>-+ +out: +---<1>-<4>-<·>-+ +out: +---<1>-<·>-+ +out: +---<2>-<3>-<4>-<·>-+ +out: +---<2>-<3>-<·>-+ +out: +---<2>-<4>-<·>-+ +out: +---<2>-<·>-+ +out: +---<3>-<4>-<·>-+ +out: +---<3>-<·>-+ +out: +---<4>-<·>-+ +out: +---<·>-+- +out: ListAllConfigs : +out: +-Conf-[-<1>-<2>-<3>-<4>-] +out: +-Conf-[-<1>-<2>-<3>-] +out: +-Conf-[-<1>-<2>-<4>-] +out: +-Conf-[-<1>-<2>-] +out: +-Conf-[-<1>-<3>-<4>-] +out: +-Conf-[-<1>-<3>-] +out: +-Conf-[-<1>-<4>-] +out: +-Conf-[-<1>-] +out: +-Conf-[-<2>-<3>-<4>-] +out: +-Conf-[-<2>-<3>-] +out: +-Conf-[-<2>-<4>-] +out: +-Conf-[-<2>-] +out: +-Conf-[-<3>-<4>-] +out: +-Conf-[-<3>-] +out: +-Conf-[-<4>-] +out: +-Conf-[-]- +out: Filter_all_possible_Configs : +out: +-Conf-[-<1>-] +out: +-Conf-[-<2>-<3>-] +out: +-Conf-[-<2>-<4>-] +out: +-Conf-[-<2>-] +out: +-Conf-[-<3>-]- +out: __________________________ +out: __________________________ check_FlagInfo() +out: Flags1 :-<1>-<3>- +out: max bit : 3 +out: binary code: 10 +out: SomeConfigs : +out: +-Conf-[-<1>-<3>-] +out: +-Conf-[-<2>-<4>-]- +out: max bit in [SomeConfigs] : 4 +out: TestVisitor application: +out: visit(code=10) --> +out: +-Conf-[-<1>-<3>-]- +out: visit(code=20) --> +out: +-Conf-[-<2>-<4>-]- +out: __________________________ +out: __________________________ check_ConfigSelector() +out: Possible_Configs : +out: +-Conf-[-<1>-] +out: +-Conf-[-<2>-<3>-] +out: +-Conf-[-<2>-<4>-] +out: +-Conf-[-<2>-] +out: +-Conf-[-<3>-]- +out: Flag-code = 2 ConfigSelector() ---> 1010 +out: Flag-code = 12 ConfigSelector() ---> 1023 +out: Flag-code = 20 ConfigSelector() ---> 1024 +out: Flag-code = 4 ConfigSelector() ---> 1020 +out: Flag-code = 8 ConfigSelector() ---> 1030 +out: LUMIERA_ERROR_INVALID:invalid input or parameters (ConfigSelector: No preconfigured factory for config-bits=10111). +return: 0 +END + + TEST "CustomSharedPtr_test" CustomSharedPtr_test < > out: ctor DoIt > out: ctor DoIt > @@ -241,6 +344,106 @@ return: 0 END +TEST "TypeListManipl_test" TypeListManipl_test <-<2>-<3>- +out: List2 :-<5>-<6>-<7>- +out: Added2 :-<3>-<4>-<5>- +out: Append1 :- +out: Append2 :-<11>-<22>- +out: Append3 :-<111>- +out: Append4 :-<222>- +out: Append5 :-<1>-<2>-<3>- +out: Append6 :-<5>-<6>-<7>- +out: Append7 :-<111>-<5>-<6>-<7>- +out: Append8 :-<1>-<2>-<3>-<222>- +out: Append9 :-<1>-<2>-<3>-<5>-<6>-<7>- +out: FilterEven :-<2>-<6>- +out: Prefix1 : +out: +---<11>-<22>-+- +out: Prefix2 : +out: +---<101>-<1>-+ +out: +---<101>-<2>-+ +out: +---<101>-<3>-+- +out: Prefix3 : +out: +---<1>-+ +out: +---<2>-+ +out: +---<3>-+- +out: Prefix4 : +out: +---<111>-<1>-<2>-<3>-+ +out: +---<111>-<0>-+ +out: +---<111>-<5>-<6>-<7>-+- +out: Prefix5 : +out: +---<1>-<2>-<3>-<5>-+ +out: +---<1>-<2>-<3>-<6>-+ +out: +---<1>-<2>-<3>-<7>-+- +out: Prefix6 : +out: +---<1>-<2>-<3>-<1>-<2>-<3>-+ +out: +---<1>-<2>-<3>-<0>-+ +out: +---<1>-<2>-<3>-<5>-<6>-<7>-+- +out: Dist1 : +out: +---<11>-<1>-+ +out: +---<11>-<2>-+ +out: +---<11>-<3>-+- +out: Dist2 : +out: +---<11>-<0>-+ +out: +---<22>-<0>-+ +out: +---<33>-<0>-+- +out: Dist3 : +out: +---<11>-<1>-+ +out: +---<11>-<2>-+ +out: +---<11>-<3>-+ +out: +---<22>-<1>-+ +out: +---<22>-<2>-+ +out: +---<22>-<3>-+ +out: +---<33>-<1>-+ +out: +---<33>-<2>-+ +out: +---<33>-<3>-+- +out: Dist4 : +out: +---<11>-<1>-<2>-<3>-+ +out: +---<11>-<5>-<6>-<7>-+ +out: +---<22>-<1>-<2>-<3>-+ +out: +---<22>-<5>-<6>-<7>-+ +out: +---<33>-<1>-<2>-<3>-+ +out: +---<33>-<5>-<6>-<7>-+- +out: Down :-<11>-<10>-<9>-<8>-<7>-<6>-<5>-<4>-<3>-<2>-<1>-<0>- +out: Combi : +out: +---<1>-<2>-<3>-<·>-+ +out: +---<1>-<2>-<2>-<·>-+ +out: +---<1>-<2>-<1>-<·>-+ +out: +---<1>-<2>-<0>-<·>-+ +out: +---<1>-<1>-<3>-<·>-+ +out: +---<1>-<1>-<2>-<·>-+ +out: +---<1>-<1>-<1>-<·>-+ +out: +---<1>-<1>-<0>-<·>-+ +out: +---<1>-<0>-<3>-<·>-+ +out: +---<1>-<0>-<2>-<·>-+ +out: +---<1>-<0>-<1>-<·>-+ +out: +---<1>-<0>-<0>-<·>-+ +out: +---<0>-<2>-<3>-<·>-+ +out: +---<0>-<2>-<2>-<·>-+ +out: +---<0>-<2>-<1>-<·>-+ +out: +---<0>-<2>-<0>-<·>-+ +out: +---<0>-<1>-<3>-<·>-+ +out: +---<0>-<1>-<2>-<·>-+ +out: +---<0>-<1>-<1>-<·>-+ +out: +---<0>-<1>-<0>-<·>-+ +out: +---<0>-<0>-<3>-<·>-+ +out: +---<0>-<0>-<2>-<·>-+ +out: +---<0>-<0>-<1>-<·>-+ +out: +---<0>-<0>-<0>-<·>-+- +out: OnOff : +out: +---<1>-<2>-<3>-<·>-+ +out: +---<1>-<2>-<·>-+ +out: +---<1>-<3>-<·>-+ +out: +---<1>-<·>-+ +out: +---<2>-<3>-<·>-+ +out: +---<2>-<·>-+ +out: +---<3>-<·>-+ +out: +---<·>-+- +return: 0 +END + + TEST "VisitingTool_test" VisitingTool_test < + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +/** @file configflagstest.cpp + ** \par build a type representing a single configuration defined by a set of flags + ** + ** The semi-automatic assembly of processing node invocation code utilizes some + ** metaprogramming to generate a factory, which in turn produces node wiring objects + ** according to the configuration to be used for the corresponding ProcNode. This relies on + ** generating a distinct type based on a given set of configuration flags, + ** which is covered by this test. + ** + ** @see configflags.hpp + ** @see typelistmanip.hpp + ** @see nodewiringconfig.hpp real world usage example + ** + */ + + +#include "common/test/run.hpp" +#include "common/meta/util.hpp" +#include "common/meta/generator.hpp" +#include "common/meta/typelistutil.hpp" +#include "common/meta/configflags.hpp" +#include "meta/typelistdiagnostics.hpp" +#include "proc/engine/nodewiringconfig.hpp" +#include "common/util.hpp" + +#include +#include + +using ::test::Test; +using std::string; +using std::cout; + + +namespace lumiera { + namespace typelist { + namespace test { + + + namespace { // internal definitions + + enum Cases + { ONE = 1 + , TWO + , THR + , FOU + , NUM_Cases = FOU + + , NOT_SET = 0 + }; + + + + /* === Test data === */ + typedef Config<> Conf0; + typedef Config Conf1; + typedef Config Conf2; + typedef Config Conf3; + typedef Config Conf4; + + typedef Flags::Tuple Flags1; + typedef Flags::Tuple Flags2; + typedef Types SomeFlagsets; + + typedef Flags::Tuple AllFlags; + typedef CombineFlags AllFlagCombinations; + + + + /** a type which is only partially defined, for some configs. + * In ConfigFlags_test::check_filter() we use the metaprogramming machinery + * to figure out all possible configs for which \c struct Maybe is defined. + * (for this to work, the "defined" specialisations need to provide a + * typedef \c is_defined ) + */ + template struct Maybe; + + struct Indeed { typedef Yes_t is_defined; }; + template<> struct Maybe : Indeed { enum{ CODE = 10 }; }; + template<> struct Maybe : Indeed { enum{ CODE = 30 }; }; + + template + struct Maybe > + { + typedef Yes_t is_defined; + + enum{ CODE = 20 + Fl }; + }; + + + } // (End) internal defs + +#define PRINT_DELIMITER(TITLE) \ + cout << "__________________________\n" \ + "__________________________ " \ + << STRINGIFY(TITLE) << "\n"; + + + + + + /************************************************************************** + * @test check the handling of types representing a specific configuration. + * Basically, this is a bitset like feature, but working on types + * instead of runtime values. The Goal is to detect automatically + * all possible defined specialisations of some template based on + * such configuration-tuples. This allows us to assemble the glue code + * for pulling data from processing nodes out of small building blocks + * in all possible configuraions. + */ + class ConfigFlags_test : public Test + { + virtual void run(Arg arg) + { + check_testdata (); + check_flags(); + check_instantiation (); + check_filter (); + check_FlagInfo (); + check_ConfigSelector (); + } + + + void check_testdata () + { + DISPLAY (Conf0); + DISPLAY (Conf1); + DISPLAY (Conf2); + DISPLAY (Conf3); + DISPLAY (Conf4); + + DISPLAY (AllFlags); + } + + + /** @test conversion between list-of-flags and a config-type in both directions */ + void check_flags () + { + PRINT_DELIMITER (check_flags()); + + typedef Config Flags1; + typedef Flags Flags2; + DISPLAY (Flags1); + DISPLAY (Flags2); + // should denote the same type + Flags1::Flags flags1 = Flags2::Tuple(); + Flags2::Tuple flags2 = flags1; + ASSERT (1==sizeof(flags1)); // pure marker-type without content + ASSERT (1==sizeof(flags2)); + + typedef DefineConfigByFlags,NullType> >::Config SimpleConfig_defined_by_Typelist; + DISPLAY (SimpleConfig_defined_by_Typelist); + + typedef DefineConfigByFlags::Config AnotherConfig_defined_by_Typelist; + DISPLAY (AnotherConfig_defined_by_Typelist); + } + + + /** @test creates a predicate template (metafunction) returning true + * iff the template \c Maybe is defined for the configuration in question + */ + void check_instantiation () + { + #define CAN_INSTANTIATE(NAME) \ + cout << "defined " \ + << STRINGIFY(NAME) \ + << "? ---> " \ + << Instantiation::Test::value << "\n"; + + PRINT_DELIMITER (check_instantiation()); + + CAN_INSTANTIATE (Conf0); + CAN_INSTANTIATE (Conf1); + CAN_INSTANTIATE (Conf2); + CAN_INSTANTIATE (Conf3); + CAN_INSTANTIATE (Conf4); + + typedef Config Trash; + CAN_INSTANTIATE (Trash); + } + + + /** @test given a list of flag-tuples, we first create config-types out of them + * and then filter out those configs for which \c template Maybe is defined + */ + void check_filter () + { + PRINT_DELIMITER (check_filter()); + + DISPLAY (SomeFlagsets); + + typedef Apply Configs_defined_by_Flagsets; + DISPLAY (Configs_defined_by_Flagsets); + + typedef Filter::Test> Filter_possible_Configs; + DISPLAY (Filter_possible_Configs); + + + DISPLAY (AllFlagCombinations); + typedef Apply ListAllConfigs; + DISPLAY (ListAllConfigs); + + typedef Filter::Test> Filter_all_possible_Configs; + DISPLAY (Filter_all_possible_Configs); + } + + + + struct TestVisitor + { + string result; + TestVisitor() : result ("TestVisitor application:\n") {} + + /* === visitation interface === */ + typedef string Ret; + + Ret done() {return result; } + + template + void + visit (ulong code) + { + result += str (format ("visit(code=%u) -->%s\n") + % code % Printer::print() ); + } + }; + + /** @test FlagInfo metafunction, which takes as argument a list-of-flags + * as well as a list-of-lists-of-flags and especially allows to + * apply a visitor object to the latter + */ + void check_FlagInfo() + { + PRINT_DELIMITER (check_FlagInfo()); + + DISPLAY (Flags1); + cout << "max bit : " << FlagInfo::BITS <<"\n"; + cout << "binary code: " << FlagInfo::CODE <<"\n"; + + typedef Apply SomeConfigs; + DISPLAY (SomeConfigs); + cout << "max bit in [SomeConfigs] : " << FlagInfo::BITS <<"\n"; + + TestVisitor visitor; + cout << FlagInfo::accept (visitor); + } + + + template + struct TestFactory + { + uint operator() () { return offset_ + Maybe::CODE; } + TestFactory(long o) : offset_(o) {} + + private: + long offset_; + }; + + + /** @test use the ConfigSelector template to build a set of factories, + * based on a set of configurations. Then invoke the apropriate + * factory by specifying the configuration bit code + */ + void check_ConfigSelector() + { + PRINT_DELIMITER (check_ConfigSelector()); + + typedef Apply ListAllConfigs; + typedef Filter::Test> Possible_Configs; + DISPLAY (Possible_Configs); + + typedef engine::config::ConfigSelector< TestFactory // Factory template + , uint(void) // Factory function type + , long // common ctor argument + > TestFactorySelector; + + const long offset = 1000; // parameter fed to all TestFactory ctors + TestFactorySelector testConfigSelector (Possible_Configs::List(), offset); + + + #define INVOKE_CONFIG_SELECTOR(CODE) \ + cout << " Flag-code = " << CODE \ + << " ConfigSelector() ---> " \ + << testConfigSelector[CODE] () << "\n"; + + INVOKE_CONFIG_SELECTOR (2); + INVOKE_CONFIG_SELECTOR (12); + INVOKE_CONFIG_SELECTOR (20); + INVOKE_CONFIG_SELECTOR (4); + INVOKE_CONFIG_SELECTOR (8); + + try + { + INVOKE_CONFIG_SELECTOR (23); + NOTREACHED ; + } + catch (lumiera::error::Invalid& err) + { + cout << err.what() << "\n"; + lumiera_error (); // reset errorflag + } + } + + + }; + + + /** Register this test class... */ + LAUNCHER (ConfigFlags_test, "unit common"); + + + + } // namespace test + + } // namespace typelist + +} // namespace lumiera diff --git a/tests/common/typelistutiltest.cpp b/tests/common/meta/generatortest.cpp similarity index 94% rename from tests/common/typelistutiltest.cpp rename to tests/common/meta/generatortest.cpp index 73cab939e..2909b076d 100644 --- a/tests/common/typelistutiltest.cpp +++ b/tests/common/meta/generatortest.cpp @@ -1,5 +1,5 @@ /* - TypeListUtil(Test) - check the typelist helpers + Generator(Test) - build an interface + implementation directed by a typelis Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,7 +21,7 @@ * *****************************************************/ -/** @file typelistutiltest.cpp +/** @file generatortest.cpp ** \par what are we doing here?? ** ** the following test composes both an interface and the corresponding implementation @@ -31,14 +31,14 @@ ** need to be absolutely fixed in the class definition) ** ** @see typelisttest.cpp - ** @see typelistutil.hpp + ** @see generator.hpp ** @see lumiera::query::ConfigRules a real world usage example ** */ #include "common/test/run.hpp" -#include "common/typelistutil.hpp" +#include "common/meta/generator.hpp" #include #include @@ -118,7 +118,7 @@ namespace lumiera * for a collection of classes * */ - class TypeListUtil_test : public Test + class TypeListGenerator_test : public Test { virtual void run(Arg arg) { @@ -144,7 +144,7 @@ namespace lumiera /** Register this test class... */ - LAUNCHER (TypeListUtil_test, "unit common"); + LAUNCHER (TypeListGenerator_test, "unit common"); diff --git a/tests/common/meta/typelistdiagnostics.hpp b/tests/common/meta/typelistdiagnostics.hpp new file mode 100644 index 000000000..8de0e8d76 --- /dev/null +++ b/tests/common/meta/typelistdiagnostics.hpp @@ -0,0 +1,170 @@ +/* + TYPELISTDIAGNOSTICS - helper for testing the typelist based utilities + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +/** @file typelistdiagnostics.hpp + ** a Printer template usable for debugging the structure of a typelist built + ** upon some simple debugging-style types. Examples being a Num template, + ** or the Flag type. A Printer type generated from this template provides + ** a static \c print() function returing a string visualizing the structure + ** of the typelist provided as parameter to the Printer template. + ** + ** @see typelistmaniptest.cpp + ** @see configflagstest.cpp + ** + */ +#ifndef META_TYPELISTDIAGNOSTICS_H +#define META_TYPELISTDIAGNOSTICS_H + + +#include "common/meta/generator.hpp" + +//#include "common/meta/typelistutil.hpp" +//#include "common/meta/util.hpp" +//#include "common/util.hpp" + +#include + +using std::string; +using boost::format; + + +namespace lumiera { + namespace typelist { + + /** constant-wrapper type for debugging purposes, + * usable for generating lists of distinguishable types + */ + template + struct Num + { + enum{ VAL=I }; + }; + + + /* some forwards used by configflagstest.cpp */ + template struct Flag; + template< char f1 + , char f2 + , char f3 + , char f4 + , char f5 + > + struct Config; + + + + namespace test { + namespace { // internal definitions + + using boost::format; + + format fmt ("-<%u>%s"); + + struct NullP + { + static string print () { return "-"; } + }; + + /** debugging template, + * printing the "number" used for intantiation on ctor call + */ + template + struct Printer; + + template + struct Printer + : BASE + { + static string print () { return str( fmt % "·" % BASE::print()); } + }; + + template + struct Printer, BASE> ///< display the presence of a Num instance in the typelist + : BASE + { + static string print () { return str( fmt % uint(Num::VAL) % BASE::print()); } + }; + + template + struct Printer, BASE> ///< display the presence of a Flag in the typelist + : BASE + { + static string print () { return str( fmt % uint(Fl) % BASE::print()); } + }; + + + + /** call the debug-print for a typelist + * utilizing the Printer template */ + template + string + printSublist () + { + typedef InstantiateChained SubList; + return SubList::print(); + } + + /** Spezialisation for debug-printing of a nested sublist */ + template + struct Printer, BASE> + : BASE + { + static string print () + { + typedef Node List; + return string("\n\t+--") + printSublist()+"+" + + BASE::print(); + } + }; + + template + struct Printer, BASE> + : BASE + { + static string print () + { + typedef typename Config::Flags FlagList; + return string("\n\t+-Conf-[") + printSublist()+"]" + + BASE::print(); + } + }; + + +#define DIAGNOSE(LIST) \ + typedef InstantiateChained Contents_##LIST; + +#define DISPLAY(NAME) \ + DIAGNOSE(NAME); cout << STRINGIFY(NAME) << "\t:" << Contents_##NAME::print() << "\n"; + + + + } // (End) internal defs + + + + } // namespace test + + } // namespace typelist + +} // namespace lumiera +#endif diff --git a/tests/common/meta/typelistmaniptest.cpp b/tests/common/meta/typelistmaniptest.cpp new file mode 100644 index 000000000..f2b86c11e --- /dev/null +++ b/tests/common/meta/typelistmaniptest.cpp @@ -0,0 +1,241 @@ +/* + TypeListManip(Test) - appending, mixing and filtering typelists + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +/** @file typelistmaniptest.cpp + ** \par checking the correct working of simple list manipulation metafunctions + ** + ** The semi-automatic assembly of processing node invocation code utilizes some + ** metaprogramming magic built upon simple list manipulation. As template metaprogramming + ** is kind-of functional programming, most of this is done by recursion. + ** To check the correct working, this test uses some constant-wrapper types and a debugging + ** template which will print these constant numbers, thus allowing to verify in the output + ** if various lists of such constant-wrapper types were manipulated as expected. + ** + ** @see typelisttest.cpp + ** @see typelistutil.hpp + ** @see nodewiringconfig.hpp real world usage example + ** + */ + + +#include "common/test/run.hpp" +#include "common/meta/generator.hpp" +#include "common/meta/typelistutil.hpp" +#include "meta/typelistdiagnostics.hpp" +#include "common/util.hpp" + +#include +#include + +using ::test::Test; +using std::string; +using std::cout; + + +namespace lumiera { + namespace typelist { + namespace test { + + + namespace { // test data + + + + typedef Types< Num<1> + , Num<2> + , Num<3> + >::List List1; + typedef Types< Num<5> + , Num<6> + , Num<7> + >::List List2; + + + template struct CountDown { typedef NullType List; }; + template<> struct CountDown > { typedef Node, NullType> List; }; + template struct CountDown > { typedef Node, typename CountDown >::List> List; }; + + + + } // (End) test data + + + + + + + /************************************************************************* + * @test check utilities for manipulating lists-of-types. + * - build an list of constant-wrapper-types and + * print them for debugging purpose. + * - append lists, single elements and NullType + * in various combinations + * - filtering out some types from a typelist by + * using a "predicate template" (metafuction) + * - building combinations and permutations + */ + class TypeListManipl_test : public Test + { + virtual void run(Arg arg) + { + check_diagnostics (); + check_apply (); + check_append (); + check_filter (); + check_prefix (); + check_distribute(); + check_combine(); + } + + + void check_diagnostics () + { + // Explanation: the DISPLAY macro expands as follows.... + typedef InstantiateChained Contents_List1; + cout << "List1" << "\t:" << Contents_List1::print() << "\n"; + + // That is: we instantiate the "Printer" template for each of the types in List1, + // forming an inheritance chain. I.e. the defined Type "Contents_List1" inherits + // from each instantiation (single inheritance). + // The print() function is defined to create a string showing each. + + DISPLAY (List2); + } + + + void check_append () + { + typedef Append Append1; + DISPLAY (Append1); + + typedef Append,Num<22> > Append2; + DISPLAY (Append2); + + typedef Append,NullType> Append3; + DISPLAY (Append3); + + typedef Append > Append4; + DISPLAY (Append4); + + typedef Append Append5; + DISPLAY (Append5); + + typedef Append Append6; + DISPLAY (Append6); + + typedef Append,List2> Append7; + DISPLAY (Append7); + + typedef Append > Append8; + DISPLAY (Append8); + + typedef Append Append9; + DISPLAY (Append9); + } + + template struct AddConst2 { typedef X Type; }; + template struct AddConst2 > { typedef Num Type; }; + + void check_apply () + { + typedef Apply Added2; + DISPLAY (Added2); + } + + + template struct IsEven { enum {value = false }; }; + template struct IsEven > { enum {value = (0 == I % 2) }; }; + + void check_filter () + { + typedef Filter::List, IsEven > FilterEven; + DISPLAY (FilterEven); + } + + + void check_prefix () + { + typedef PrefixAll,Num<22> > Prefix1; + DISPLAY (Prefix1); + + typedef PrefixAll,List1> Prefix2; + DISPLAY (Prefix2); + + typedef PrefixAll Prefix3; + DISPLAY (Prefix3); + + typedef Types,List2::List>::List List_of_Lists; + typedef PrefixAll,List_of_Lists> Prefix4; + DISPLAY (Prefix4); + + typedef PrefixAll Prefix5; + DISPLAY (Prefix5); + + typedef PrefixAll Prefix6; + DISPLAY (Prefix6); + } + + + void check_distribute() + { + typedef Distribute, List1> Dist1; + DISPLAY (Dist1); + + typedef Types,Num<22>,Num<33> >::List Prefixes; + typedef Distribute > Dist2; + DISPLAY (Dist2); + + typedef Distribute Dist3; + DISPLAY (Dist3); + + typedef Distribute::List> Dist4; + DISPLAY (Dist4); + } + + + void check_combine() + { + typedef CountDown > Down; + DISPLAY (Down); + + typedef Combine Combi; + DISPLAY (Combi); + + typedef CombineFlags OnOff; + DISPLAY (OnOff); + } + + + }; + + + /** Register this test class... */ + LAUNCHER (TypeListManipl_test, "unit common"); + + + + } // namespace test + + } // namespace typelist + +} // namespace lumiera diff --git a/tests/common/typelisttest.cpp b/tests/common/meta/typelisttest.cpp similarity index 98% rename from tests/common/typelisttest.cpp rename to tests/common/meta/typelisttest.cpp index 42159d96c..5c942b1e0 100644 --- a/tests/common/typelisttest.cpp +++ b/tests/common/meta/typelisttest.cpp @@ -22,7 +22,7 @@ #include "common/test/run.hpp" -#include "common/typelist.hpp" +#include "common/meta/typelist.hpp" #include diff --git a/tests/components/proc/engine/bufftabletest.cpp b/tests/components/proc/engine/bufftabletest.cpp new file mode 100644 index 000000000..420d30636 --- /dev/null +++ b/tests/components/proc/engine/bufftabletest.cpp @@ -0,0 +1,180 @@ +/* + BuffTable(Test) - check consistency of buffer table chunk allocation + + Copyright (C) Lumiera.org + 2008, Hermann Vosseler + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +* *****************************************************/ + + +#include "common/test/run.hpp" +#include "common/error.hpp" + +#include "proc/engine/procnode.hpp" +#include "proc/engine/bufftable.hpp" + +#include +#include +#include +#include + +using test::Test; +using std::cout; +using std::rand; + + +namespace engine { + namespace test { + + namespace { // used internally + + const uint TABLE_SIZ = 100000; + const uint CHUNK_MAX = 8000; + const uint WIDTH_MAX = 3; + + + /** just some crap to pass in as ctor argument... */ + template + struct DummyArray : RefArray + { + E decoy; + E const& operator[] (uint i) const { return decoy;} + }; + DummyArray dummy1; + DummyArray dummy2; + + + /** a "hijacked" WiringDescriptor requesting + * a random number of inputs and outputs */ + struct MockSizeRequest + : WiringDescriptor + { + uint ii,oo; + + MockSizeRequest() + : WiringDescriptor(dummy1,dummy2,0), + ii(rand() % CHUNK_MAX), + oo(rand() % CHUNK_MAX) + { } + + virtual uint getNrI() const { return ii; } + virtual uint getNrO() const { return oo; } + + virtual BuffHandle callDown (State&, uint) const + { throw lumiera::Error("not intended to be called"); } + }; + + + + void* + detect_start_level (BuffTableStorage& sto) + { + return BuffTableChunk(MockSizeRequest(), sto ).outHandle; + } // address of first available storage element + + + inline void* + first_behind (BuffTable const& thisChunk, const uint nrI) + { + return &thisChunk.inHandle[nrI]; + } + + + inline bool + not_within(void* candidate, void* lower, void* upper) + { + return (candidate < lower) || (upper <= candidate); + } + + + bool + consistencyCheck (BuffTable const& b, WiringDescriptor const& num, void* lastLevel) + { + return (b.outHandle == lastLevel ) // storage is allocated continously + && (b.outBuff <= b.inBuff ) // input slots are behind the output slots + && (b.outHandle <= b.inHandle) + && (b.inBuff == &b.outBuff [num.getNrO()]) + && (b.inHandle == &b.outHandle[num.getNrO()]) + && (not_within(b.outBuff, b.outHandle, &b.inHandle[num.getNrO()])) // storage doesn't overlap + && (not_within(b.inBuff, b.outHandle, &b.inHandle[num.getNrO()])) + && (not_within(b.outHandle, b.outBuff, &b.inBuff[num.getNrO()])) + && (not_within(b.inHandle, b.outBuff, &b.inBuff[num.getNrO()])) + ; + } + } // (End) internal defs + + + + /******************************************************************* + * @test create a random pattern of recursive invocations, each + * allocating a chunk out of a global buffer table storage. + * After returning, each allocation should be cleanly + * deallocated and the internal level in the storage vector + * should have dopped to zero again. + */ + class BuffTable_test : public Test + { + typedef boost::scoped_ptr PSto; + + PSto pStorage; + ulong counter; + + virtual void run(Arg arg) + { + counter = 0; + std::srand (time (NULL)); + + // allocate storage block to be used chunk wise + pStorage.reset (new BuffTableStorage (TABLE_SIZ)); + + invocation (0, detect_start_level(*pStorage)); + + pStorage.reset(0); // dtor throws assertion error if corrupted + + cout << "BuffTable chunks allocated: "< - b multiplicity "" parent class_ref 132741 // StateProxy + b multiplicity "" parent class_ref 132741 // State end attribute 129413 "start" @@ -233,6 +243,46 @@ ${members}}; classrelation_ref 137861 // params () b multiplicity "" parent class_ref 134533 // Parameter end + + classrelation 152581 // predecessors () + relation 149125 *--> + stereotype "array" + a role_name "predecessors" multiplicity "*" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; +" + classrelation_ref 152581 // predecessors () + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + + operation 135685 "pull" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136069 "process" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end end class 131845 "Trafo" @@ -275,26 +325,6 @@ ${inlines} end end - class 132101 "Hub" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - classrelation 133125 // - relation 132357 ---|> - a public - cpp default "${type}" - classrelation_ref 133125 // - b multiplicity "" parent class_ref 131717 // ProcNode - end - end - class 132229 "Projector" visibility package cpp_decl "${comment}${template}class ${name}${inherit} @@ -377,90 +407,6 @@ ${inlines} end end - class 132613 "GLPipe" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "specialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form" - classrelation 133381 // - relation 132613 ---|> - a public - cpp default "${type}" - classrelation_ref 133381 // - b multiplicity "" parent class_ref 131973 // Link - end - end - - class 132869 "ARender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a Audio render process" - classrelation 134661 // - relation 133509 ---|> - a public - cpp default "${type}" - classrelation_ref 134661 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - - class 132997 "VRender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)" - classrelation 134789 // - relation 133637 ---|> - a public - cpp default "${type}" - classrelation_ref 134789 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - - class 133125 "GLRender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a OpenGL accelerated Video render process" - classrelation 134917 // - relation 133765 ---|> - a public - cpp default "${type}" - classrelation_ref 134917 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - class 133253 "Frame" abstract visibility public stereotype "interface" cpp_decl "${comment}${template}class ${name}${inherit} @@ -568,5 +514,476 @@ ${inlines} b multiplicity "" parent class_ref 136709 // Media end end + + class 142469 "StateProxy" + visibility package stereotype "implementation" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152453 // + relation 148997 ---|> + a public + cpp default "${type}" + classrelation_ref 152453 // + b multiplicity "" parent class_ref 132741 // State + end + + end + + class 142597 "StateAdapter" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152325 // + relation 148869 ---|> + a public + cpp default "${type}" + classrelation_ref 152325 // + b multiplicity "" parent class_ref 132741 // State + end + + operation 135557 "retrieve" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + classrelation 152709 // state () + relation 149253 ---> + a role_name "state" multiplicity "1" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 152709 // state () + b multiplicity "" parent class_ref 142469 // StateProxy + end + + classrelation 152837 // + relation 149381 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 152837 // + b multiplicity "" parent class_ref 133253 // Frame + end + end + + class 142725 "WiringDescriptor" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + operation 136453 "callDown" + cpp_virtual public explicit_return_type "" + nparams 2 + param inout name "" type class_ref 132741 // State + param in name "requiredOutput" explicit_type "uint" + nexceptions 1 + exception class_ref 144133 // BuffHandle + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + end + + class 143365 "NodeWiring" + visibility package + nformals 1 + formal name "CONF" type "class" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152965 // + relation 149509 ---|> + a public + cpp default "${type}" + classrelation_ref 152965 // + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + + classrelation 153093 // + relation 149637 -_-> + a default + cpp default "#include in header" + classrelation_ref 153093 // + b multiplicity "" parent class_ref 142597 // StateAdapter + end + + classrelation 156165 // + relation 152581 ---- + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156165 // + b role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156293 // + end + + classrelation 156421 // + relation 152709 ---- + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156421 // + b role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156549 // + end + + classrelation 156677 // + relation 152837 ---- + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156677 // + b role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156805 // + end + + classrelation 156933 // + relation 152965 ---> + stereotype "creates" + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156933 // + b multiplicity "" parent class_ref 144261 // Invocation + end + + operation 136581 "callDown" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + end + + class 143493 "OperationBase" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 143621 "QueryCache" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 157189 // + relation 153221 ---|> + a public + cpp default "${type}" + classrelation_ref 157189 // + b multiplicity "" parent class_ref 143749 // PullInput + end + end + + class 143749 "PullInput" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 157317 // + relation 153349 ---|> + a public + cpp default "${type}" + classrelation_ref 157317 // + b multiplicity "" parent class_ref 144389 // ProcessData + end + + classrelation 158085 // + relation 154117 ---- + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 158085 // + b role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 158213 // + end + end + + class 143877 "ReadSource" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 157701 // + relation 153733 ---|> + a public + cpp default "${type}" + classrelation_ref 157701 // + b multiplicity "" parent class_ref 143493 // OperationBase + end + end + + class 144389 "ProcessData" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 157445 // + relation 153477 ---|> + a public + cpp default "${type}" + classrelation_ref 157445 // + b multiplicity "" parent class_ref 144645 // FeedCache + end + + classrelation 157829 // + relation 153861 ---|> + a public + cpp default "${type}" + classrelation_ref 157829 // + b multiplicity "" parent class_ref 143493 // OperationBase + end + + classrelation 158213 // + relation_ref 154117 // + end + end + + class 144645 "FeedCache" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 157573 // + relation 153605 ---|> + a public + cpp default "${type}" + classrelation_ref 157573 // + b multiplicity "" parent class_ref 143493 // OperationBase + end + end + + class 144517 "Strategy" + visibility package + nformals 1 + formal name "CONF" type "class" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 154757 // + relation 151301 ---|> + a public + cpp default "${type}" + classrelation_ref 154757 // + b multiplicity "" parent class_ref 143877 // ReadSource + end + + classrelation 156293 // + relation_ref 152581 // + end + + classrelation 156549 // + relation_ref 152709 // + end + + classrelation 156805 // + relation_ref 152837 // + end + + classrelation 157061 // + relation 153093 ---|> + a public + cpp default "${type}" + classrelation_ref 157061 // + b multiplicity "" parent class_ref 143621 // QueryCache + end + + classrelation 157957 // + relation 153989 ---|> + a public + cpp default "${type}" + classrelation_ref 157957 // + b multiplicity "" parent class_ref 143749 // PullInput + end + end + + class 144005 "BuffTable" + visibility package + nformals 1 + formal name "SIZ" type "int" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153861 // + relation 150405 *--> + stereotype "array" + a role_name "" multiplicity "SIZ" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; +" + classrelation_ref 153861 // + b multiplicity "" parent class_ref 144133 // BuffHandle + end + + classrelation 153989 // + relation 150533 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 153989 // + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + end + + class 144133 "BuffHandle" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 144261 "Invocation" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 155781 // + relation 152197 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 155781 // + b multiplicity "" parent class_ref 142597 // StateAdapter + end + + classrelation 155909 // + relation 152325 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 155909 // + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + + classrelation 156037 // + relation 152453 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 156037 // + b multiplicity "" parent class_ref 144005 // BuffTable + end + end end end diff --git a/uml/lumiera/128389.diagram b/uml/lumiera/128389.diagram index 5a6ad5049..da7bca1cb 100644 --- a/uml/lumiera/128389.diagram +++ b/uml/lumiera/128389.diagram @@ -14,7 +14,7 @@ classcanvas 128389 class_ref 131589 // ExitNode end classcanvas 128517 class_ref 131717 // ProcNode draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 462 264 2000 + xyz 462 257 2000 end classcanvas 129029 class_ref 131845 // Trafo draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default @@ -24,10 +24,6 @@ classcanvas 129157 class_ref 131973 // Link draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 648 444 2000 end -classcanvas 129285 class_ref 132101 // Hub - draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 593 444 2000 - end classcanvas 129413 class_ref 132229 // Projector draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 417 561 2000 @@ -40,26 +36,10 @@ classcanvas 129669 class_ref 132485 // PluginAdapter draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 506 621 2000 end -classcanvas 129797 class_ref 132613 // GLPipe - draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 699 531 2000 - end -classcanvas 132229 class_ref 132741 // StateProxy +classcanvas 132229 class_ref 132741 // State draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 36 374 2000 end -classcanvas 132997 class_ref 132869 // ARender - draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 31 511 2000 - end -classcanvas 133125 class_ref 132997 // VRender - draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 110 511 2000 - end -classcanvas 133253 class_ref 133125 // GLRender - draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 175 511 2000 - end classcanvas 133765 class_ref 133253 // Frame draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 269 612 2000 @@ -97,36 +77,25 @@ relationcanvas 128901 relation_ref 131973 // multiplicity_a_pos 414 419 3000 no_multiplicity_b relationcanvas 129925 relation_ref 132101 // geometry VHV - from ref 128389 z 1999 to point 445 384 - line 130693 z 1999 to point 499 384 + from ref 128389 z 1999 to point 445 397 + line 130693 z 1999 to point 499 397 line 130821 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 130053 relation_ref 132229 // geometry VHV - from ref 129029 z 1999 to point 516 383 - line 130949 z 1999 to point 499 383 + from ref 129029 z 1999 to point 516 397 + line 130949 z 1999 to point 499 397 line 131077 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 130181 relation_ref 132357 // - geometry VHV - from ref 129285 z 1999 to point 613 384 - line 131205 z 1999 to point 499 384 - line 131333 z 1999 to ref 128517 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 130309 relation_ref 132485 // geometry VHV - from ref 129157 z 1999 to point 668 384 - line 131461 z 1999 to point 499 384 + from ref 129157 z 1999 to point 668 397 + line 131461 z 1999 to point 499 397 line 131589 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 131717 relation_ref 132613 // - from ref 129797 z 1999 to ref 129157 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 131845 relation_ref 132741 // from ref 129413 z 1999 to ref 129029 no_role_a no_role_b @@ -139,27 +108,6 @@ relationcanvas 132101 relation_ref 132997 // from ref 129669 z 1999 to ref 129029 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 133381 relation_ref 133509 // - geometry VHV - from ref 132997 z 1999 to point 58 472 - line 134277 z 1999 to point 73 472 - line 134405 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b -relationcanvas 133509 relation_ref 133637 // - geometry VHV - from ref 133125 z 1999 to point 136 472 - line 134533 z 1999 to point 73 472 - line 134661 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b -relationcanvas 133637 relation_ref 133765 // - geometry VHV - from ref 133253 z 1999 to point 206 472 - line 134789 z 1999 to point 73 472 - line 134917 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 135045 relation_ref 133893 // geometry VHV from ref 133893 z 1999 to point 252 704 @@ -179,14 +127,14 @@ relationcanvas 135429 relation_ref 134149 // no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 136965 relation_ref 134533 // - from ref 132229 z 1999 to point 306 465 + from ref 132229 z 1999 stereotype "<>" xyz 279 441 3000 to point 306 465 line 137093 z 1999 to ref 133765 role_a_pos 318 587 3000 no_role_b no_multiplicity_a multiplicity_b_pos 124 427 3000 relationcanvas 137349 relation_ref 134661 // geometry VHV - from ref 137221 z 1999 to point 763 384 - line 137477 z 1999 to point 499 384 + from ref 137221 z 1999 to point 763 397 + line 137477 z 1999 to point 499 397 line 137605 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b @@ -203,8 +151,8 @@ relationcanvas 139397 relation_ref 135429 // from ref 128517 z 1999 to point 432 264 line 139525 z 1999 to point 432 294 line 139653 z 1999 to ref 128517 - role_a_pos 414 272 3000 no_role_b - no_multiplicity_a multiplicity_b_pos 445 291 3000 + role_a_pos 414 276 3000 no_role_b + no_multiplicity_a multiplicity_b_pos 445 296 3000 relationcanvas 139909 relation_ref 136965 // from ref 139781 z 1999 to ref 129029 no_role_a no_role_b diff --git a/uml/lumiera/128901 b/uml/lumiera/128901 index e4d919380..9a2bf5b90 100644 --- a/uml/lumiera/128901 +++ b/uml/lumiera/128901 @@ -1,6 +1,6 @@ format 40 "Builder" // ProcessingLayer::MObject::Builder - revision 14 + revision 17 modified_by 5 "hiv" // class settings //class diagram settings @@ -299,7 +299,7 @@ ${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} end end - class 132741 "StateProxy" + class 132741 "State" abstract visibility public stereotype "interface" cpp_decl "${comment}${template}class ${name}${inherit} { @@ -316,12 +316,73 @@ ${members}}; classrelation 135941 // currFrame () relation 134533 ---> + stereotype "vector" a role_name "currFrame" multiplicity "" protected cpp default " ${comment}${static}${mutable}${volatile}${const}${type} * ${name}${value}; " classrelation_ref 135941 // currFrame () b multiplicity "1" parent class_ref 133253 // Frame end + + operation 135813 "fetch" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 135941 "allocateBuffer" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136197 "releaseBuffer" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136325 "isCalculated" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end end class 134021 "Buildable" diff --git a/uml/lumiera/129029.diagram b/uml/lumiera/129029.diagram index 9892c6c73..7ca7da511 100644 --- a/uml/lumiera/129029.diagram +++ b/uml/lumiera/129029.diagram @@ -33,12 +33,6 @@ classinstancecanvas 129797 classinstance_ref 131717 // vid_a classinstancecanvas 129925 classinstance_ref 131845 // aud_a xyz 444 398 2000 end -classinstancecanvas 131717 classinstance_ref 131973 // vid1 - xyz 188 427 2000 - end -classinstancecanvas 131845 classinstance_ref 132101 // au1 - xyz 554 289 2000 - end classinstancecanvas 131973 classinstance_ref 132229 // xyz 117 492 2000 end @@ -49,9 +43,15 @@ note 133125 "render state proxy passed on" xyzwh 123 355 2000 104 53 textcanvas 133253 "Video and Audio Clip of length = 5 frames positioned at frame 2, producing two output streams (frame sequence)." xyzwh 445 507 2000 175 83 +classinstancecanvas 133381 classinstance_ref 137093 // vid1 + xyz 172 431 2000 + end +classinstancecanvas 133893 classinstance_ref 137221 // au1 + xyz 556 289 2000 + end objectlinkcanvas 128389 rel relation_ref 131845 // geometry VH - from ref 128005 z 1999 to point 117 205 + from ref 128005 z 1999 stereotype "<>" xyz 101 154 3000 to point 117 205 line 81 z 1999 to ref 128261 role_a_pos 188 183 3000 no_role_b objectlinkcanvas 128901 rel relation_ref 131973 // @@ -75,20 +75,18 @@ objectlinkcanvas 131461 rel relation_ref 135429 // objectlinkcanvas 131589 rel relation_ref 135429 // from ref 128773 z 1999 to ref 129925 role_a_pos 494 373 3000 no_role_b -objectlinkcanvas 132229 rel relation_ref 134533 // +objectlinkcanvas 133509 norel geometry VHr - from ref 131717 z 1999 to point 140 438 - line 1 z 1999 to ref 131973 - role_a_pos 152 467 3000 no_role_b -objectlinkcanvas 132485 rel relation_ref 134533 // + from ref 133381 z 1999 to point 140 442 + line 133637 z 1999 to ref 131973 + no_role_a no_role_b +objectlinkcanvas 134021 norel geometry HV - from ref 131845 z 1999 to point 676 300 - line 1 z 1999 to ref 132101 - role_a_pos 688 328 3000 no_role_b -line 132613 -_-_ - from ref 128261 z 1999 to point 244 320 - line 132741 z 1999 to ref 131717 -line 132869 -_-_ - from ref 128133 z 1999 to point 583 259 - line 132997 z 1999 to ref 131845 + from ref 133893 z 1999 to point 676 300 + line 134149 z 1999 to ref 132101 + no_role_a no_role_b +line 133765 -_-_ + from ref 128261 z 1999 to ref 133381 +line 134277 -_-_ + from ref 128133 z 1999 to ref 133893 end diff --git a/uml/lumiera/129157.diagram b/uml/lumiera/129157.diagram index f63b08370..81552e7a1 100644 --- a/uml/lumiera/129157.diagram +++ b/uml/lumiera/129157.diagram @@ -26,11 +26,8 @@ end classinstancecanvas 129157 classinstance_ref 133253 // HUE xyz 477 444 2000 end -classinstancecanvas 129541 classinstance_ref 133381 // vid1 - xyz 409 293 2000 - end classinstancecanvas 129669 classinstance_ref 133509 // - xyz 138 498 2000 + xyz 151 399 2000 end classinstancecanvas 129797 classinstance_ref 133637 // video1 xyz 478 172 2000 @@ -60,6 +57,9 @@ note 134661 "Note: because the Engine Components are stateless, various calculat xyzwh 569 45 2000 240 75 textcanvas 134789 "Video Clip from 2 to 7, with an attached HUE effect starting 3 frames after begin and overlapping by 1 frame beyond the end" xyzwh 145 553 2000 175 87 +classinstancecanvas 134917 classinstance_ref 137093 // vid1 + xyz 410 291 3005 + end objectlinkcanvas 130053 rel relation_ref 135429 // from ref 129925 z 1999 to ref 128901 role_a_pos 537 361 3000 no_role_b @@ -67,46 +67,46 @@ objectlinkcanvas 130437 rel relation_ref 135429 // from ref 129157 z 1999 to ref 128645 role_a_pos 539 472 3000 no_role_b objectlinkcanvas 130565 rel relation_ref 131973 // - from ref 128773 z 1999 stereotype "<>" xyz 624 285 3000 to ref 128517 + from ref 128773 z 1999 stereotype "<>" xyz 656 263 3000 to ref 128517 role_a_pos 661 304 3000 no_role_b -objectlinkcanvas 130693 rel relation_ref 134533 // - geometry VHr - from ref 129541 z 1999 to point 161 304 - line 130821 z 1999 to ref 129669 - role_a_pos 173 473 3000 no_role_b -objectlinkcanvas 130949 rel relation_ref 135429 // - from ref 128901 z 1999 to ref 129157 - role_a_pos 538 419 3000 no_role_b -objectlinkcanvas 131589 rel relation_ref 131973 // - from ref 129797 z 1999 stereotype "<>" xyz 499 284 3000 to ref 129925 - role_a_pos 537 304 3000 no_role_b -objectlinkcanvas 132613 rel relation_ref 135429 // - from ref 128517 z 1999 to ref 132229 - role_a_pos 662 419 3000 no_role_b -objectlinkcanvas 132869 rel relation_ref 135429 // - from ref 132229 z 1999 to ref 128389 - role_a_pos 662 533 3000 no_role_b -objectlinkcanvas 133637 rel relation_ref 135429 // - from ref 133509 z 1999 to ref 133381 - role_a_pos 348 361 3000 no_role_b -objectlinkcanvas 133765 rel relation_ref 135429 // - from ref 133125 z 1999 to ref 132997 - role_a_pos 416 577 3000 no_role_b -objectlinkcanvas 133893 rel relation_ref 131973 // - from ref 133253 z 1999 stereotype "<>" xyz 291 273 3000 to ref 133509 - role_a_pos 348 304 3000 no_role_b -objectlinkcanvas 134277 rel relation_ref 135429 // - from ref 133381 z 1999 to ref 133125 - role_a_pos 349 473 3000 no_role_b -objectlinkcanvas 134405 rel relation_ref 135429 // +objectlinkcanvas 135045 rel relation_ref 135429 // from ref 128645 z 1999 to ref 132997 role_a_pos 446 567 3000 no_role_b -objectlinkcanvas 134533 rel relation_ref 131845 // +objectlinkcanvas 135173 rel relation_ref 131845 // geometry VH - from ref 128005 z 1999 to point 123 205 - line 6 z 1999 to ref 133253 - role_a_pos 197 183 3000 no_role_b -line 131973 -_-_ - from ref 129797 z 1999 to point 445 243 - line 132101 z 1999 to ref 129541 + from ref 128005 z 1999 stereotype "<>" xyz 127 141 3000 to point 123 205 + line 136965 z 1999 to ref 133253 + role_a_pos 152 186 3000 no_role_b +objectlinkcanvas 135301 rel relation_ref 135429 // + from ref 128901 z 1999 to ref 129157 + role_a_pos 538 419 3000 no_role_b +objectlinkcanvas 135429 rel relation_ref 131973 // + from ref 133253 z 1999 stereotype "<>" xyz 282 261 3000 to ref 133509 + role_a_pos 348 304 3000 no_role_b +objectlinkcanvas 135557 rel relation_ref 135429 // + from ref 128517 z 1999 to ref 132229 + role_a_pos 662 419 3000 no_role_b +objectlinkcanvas 135685 rel relation_ref 135429 // + from ref 133125 z 1999 to ref 132997 + role_a_pos 416 577 3000 no_role_b +objectlinkcanvas 135813 rel relation_ref 135429 // + from ref 132229 z 1999 to ref 128389 + role_a_pos 662 533 3000 no_role_b +objectlinkcanvas 135941 rel relation_ref 131973 // + from ref 129797 z 1999 stereotype "<>" xyz 529 262 3000 to ref 129925 + role_a_pos 537 304 3000 no_role_b +objectlinkcanvas 136069 rel relation_ref 135429 // + from ref 133509 z 1999 to ref 133381 + role_a_pos 348 361 3000 no_role_b +objectlinkcanvas 136197 rel relation_ref 135429 // + from ref 133381 z 1999 to ref 133125 + role_a_pos 349 473 3000 no_role_b +objectlinkcanvas 136325 norel + geometry VHr + from ref 134917 z 1999 to point 174 302 + line 136453 z 1999 to ref 129669 + no_role_a no_role_b +line 136581 -_-_ + from ref 129797 z 1999 to point 451 237 + line 136709 z 1999 to ref 134917 end diff --git a/uml/lumiera/129285 b/uml/lumiera/129285 index 28f619bb6..1441c4bdf 100644 --- a/uml/lumiera/129285 +++ b/uml/lumiera/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 14 + revision 22 modified_by 5 "hiv" // class settings //class diagram settings @@ -391,26 +391,6 @@ format 40 end end - classinstance 131973 "vid1" - type class_ref 132997 // VRender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 132229 // - end - end - - classinstance 132101 "au1" - type class_ref 132869 // ARender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 132357 // - end - end - classinstance 132229 "" type class_ref 133509 // VFrame attributes @@ -499,16 +479,6 @@ format 40 end end - classinstance 133381 "vid1" - type class_ref 132997 // VRender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 133509 // - end - end - classinstance 133509 "" type class_ref 133509 // VFrame attributes @@ -602,5 +572,108 @@ format 40 classinstance_ref 134405 // ouput end end + + collaborationdiagram 132229 "Render Process" + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + size A4 + end + + classinstance 136197 "node1" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136325 "ad1" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + classinstance 136453 "current" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end + + classinstance 136581 "node2" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136709 "ad2" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + class 143109 "BackendCache" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 143237 "Caller" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + classinstance 136837 "node3" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136965 "ad3" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + classinstance 137093 "vid1" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end + + classinstance 137221 "au1" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end end end diff --git a/uml/lumiera/130309 b/uml/lumiera/130309 index f5c27c9a0..e89c34727 100644 --- a/uml/lumiera/130309 +++ b/uml/lumiera/130309 @@ -1,6 +1,6 @@ format 40 "engine" // design::codegen::proc::engine - revision 8 + revision 9 modified_by 5 "hiv" // class settings //class diagram settings @@ -306,7 +306,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132101 // Hub end comment "special ProcNode used to build data distributing connections" end @@ -501,7 +500,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132613 // GLPipe end comment "specialized connection element for handling OpenGL implementation details" end @@ -540,7 +538,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132869 // ARender end comment "Representation of a Audio Render process" end @@ -579,7 +576,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132997 // VRender end comment "Representation of a Video render process" end @@ -618,7 +614,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 133125 // GLRender end comment "Representation of a OpenGL accellerated Video render process" end diff --git a/uml/lumiera/131973.diagram b/uml/lumiera/131973.diagram new file mode 100644 index 000000000..dda416518 --- /dev/null +++ b/uml/lumiera/131973.diagram @@ -0,0 +1,85 @@ +format 40 + +classcanvas 128005 class_ref 131717 // ProcNode + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 103 405 2004 + end +classcanvas 128517 class_ref 132741 // State + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 77 18 2000 + end +classcanvas 129669 class_ref 133253 // Frame + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 264 313 3005 + end +classcanvas 131845 class_ref 142469 // StateProxy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 126 220 2000 + end +classcanvas 131973 class_ref 142597 // StateAdapter + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 40 317 3010 + end +classcanvas 132357 class_ref 142725 // WiringDescriptor + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + hidden_operations + operation_ref 136453 // callDown + xyz 229 498 2000 + end +classcanvas 135045 class_ref 143365 // NodeWiring + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 241 561 2000 + end +textcanvas 135685 "determines concrete Type" + xyzwh 100 594 2004 130 18 +relationcanvas 129797 relation_ref 134533 // + from ref 128517 z 1999 stereotype "<>" xyz 277 115 3000 to point 300 136 + line 130053 z 1999 to ref 129669 + role_a_pos 312 288 3000 no_role_b + no_multiplicity_a multiplicity_b_pos 173 109 3000 +relationcanvas 132101 relation_ref 148869 // + geometry VHV unfixed + from ref 131973 z 1999 to point 78 186 + line 134021 z 1999 to point 118 186 + line 134149 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 132229 relation_ref 148997 // + geometry VHV + from ref 131845 z 1999 to point 178 186 + line 134277 z 1999 to point 118 186 + line 134405 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 132485 relation_ref 149125 // + geometry HV + from ref 128005 z 1999 stereotype "<>" xyz 205 454 3000 to point 277 452 + line 133381 z 1999 to ref 132357 + role_a_pos 289 473 3000 no_role_b + multiplicity_a_pos 265 473 3000 no_multiplicity_b +relationcanvas 133509 relation_ref 149253 // + from ref 131973 z 1999 to point 178 312 + line 133637 z 1999 to ref 131845 + role_a_pos 190 293 3000 no_role_b + multiplicity_a_pos 164 293 3000 no_multiplicity_b +relationcanvas 134533 relation_ref 149381 // + from ref 131973 z 3004 to ref 129669 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135173 relation_ref 149509 // + from ref 135045 z 1999 to ref 132357 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135301 relation_ref 149637 // + geometry VHr + from ref 135045 z 1999 to point 78 596 + line 135557 z 1999 to ref 131973 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +line 134661 -_-_ + from ref 131973 z 2003 to ref 128005 +line 134789 -_-_ + from ref 131973 z 2003 to point 134 414 + line 134917 z 2003 to ref 128005 +preferred_whz 414 544 1 +end diff --git a/uml/lumiera/132229.diagram b/uml/lumiera/132229.diagram new file mode 100644 index 000000000..af599827d --- /dev/null +++ b/uml/lumiera/132229.diagram @@ -0,0 +1,184 @@ +format 40 + +classinstancecanvas 128261 classinstance_ref 136197 // node1 + xyz 152 504 2000 + end +classinstancecanvas 128389 classinstance_ref 136325 // ad1 + xyz 191 393 2000 + end +classinstancecanvas 128517 classinstance_ref 136453 // current + xyz 188 92 2000 + end +classinstancecanvas 128645 classinstance_ref 136581 // node2 + xyz 388 393 2000 + end +classinstancecanvas 128773 classinstance_ref 136709 // ad2 + xyz 422 301 2000 + end +classinstance 128901 class_ref 143109 // BackendCache + name "" xyz 692 12 2000 +classinstance 129029 class_ref 143237 // Caller + name "" xyz 28 505 2000 +classinstancecanvas 130949 classinstance_ref 136837 // node3 + xyz 625 300 2000 + end +classinstancecanvas 131077 classinstance_ref 136965 // ad3 + xyz 665 199 2000 + end +textcanvas 133381 "node1 using node2 as predecessor; calculates in-place, will push result to Cache" + xyzwh 149 538 2000 408 21 +textcanvas 133509 "node2 using node3 as predecessor. Calculates without caching" + xyzwh 385 427 2005 350 18 +textcanvas 133637 "node3 doesn't calc, but fetch result from Cache" + xyzwh 564 329 2000 231 18 +linkcanvas 129157 + from ref 129029 z 1999 to ref 128261 +dirscanvas 129285 z 1000 linkcanvas_ref 129157 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "1 pull()" xyz 97 480 3000 +linkcanvas 129413 + from ref 128261 z 1999 to ref 128389 +dirscanvas 130309 z 1000 linkcanvas_ref 129413 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "2 retrieve()" xyz 141 437 3000 + backward_label "16 process()" xyz 236 471 3000 +linkcanvas 129541 + from ref 128389 z 1999 to ref 128517 +dirscanvas 131717 z 1000 linkcanvas_ref 129541 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "3 fetch() +11 allocateBuffer() +17 isCalculated()" xyz 128 228 3000 +linkcanvas 129669 + from ref 128389 z 1999 to ref 128645 +dirscanvas 130437 z 1000 linkcanvas_ref 129669 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "4 pull()" xyz 319 369 3000 +linkcanvas 129797 + from ref 128645 z 1999 to ref 128773 +dirscanvas 130693 z 1000 linkcanvas_ref 129797 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "5 retrieve()" xyz 379 349 3000 + backward_label "13 process()" xyz 469 372 3000 +linkcanvas 130181 + from ref 128773 z 1999 to ref 128517 +dirscanvas 133765 z 1000 linkcanvas_ref 130181 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "14 releaseBuffer()" xyz 285 227 3000 +linkcanvas 131205 + from ref 128773 z 1999 to ref 130949 +dirscanvas 131845 z 1000 linkcanvas_ref 131205 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "6 pull()" xyz 553 276 3000 +linkcanvas 131333 + from ref 130949 z 1999 to ref 131077 +dirscanvas 131973 z 1000 linkcanvas_ref 131333 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "7 retrieve()" xyz 615 236 3000 +linkcanvas 131461 + from ref 131077 z 1999 to ref 128517 +dirscanvas 132101 z 1000 linkcanvas_ref 131461 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "8 fetch()" xyz 449 179 3000 +linkcanvas 131589 + from ref 128517 z 1999 to point 295 24 + line 134277 z 1999 to ref 128901 +dirscanvas 132229 z 1000 linkcanvas_ref 134277 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "9 fetch +12 allocateNewFrame +15 releaseFrame +18 isCalculatedFrame +20 releaseFrame" xyz 487 29 3000 +linkcanvas 132357 + from ref 131077 z 1999 to point 515 211 + line 132613 z 1999 to ref 128773 +dirscanvas 132741 z 1000 linkcanvas_ref 132357 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default +linkcanvas 132485 + from ref 128773 z 1999 to point 280 312 + line 132869 z 1999 to ref 128389 +dirscanvas 132997 z 1000 linkcanvas_ref 132485 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "10 allocateBuffer()" xyz 306 293 3000 +linkcanvas 133893 + from ref 129029 z 1999 to point 49 155 + line 134021 z 1999 to ref 128517 +dirscanvas 134149 z 1000 linkcanvas_ref 134021 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "19 releaseBuffer()" xyz 65 100 3000 +msgs + msg operation_ref 135685 // "pull()" + forward ranks 1 "1" dirscanvas_ref 129285 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 2 "1.1" dirscanvas_ref 130309 + msgs + msg operation_ref 135813 // "fetch()" + forward ranks 3 "1.1.1" dirscanvas_ref 131717 + no_msg + msg operation_ref 135685 // "pull()" + forward ranks 4 "1.1.2" dirscanvas_ref 130437 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 5 "1.1.2.1" dirscanvas_ref 130693 + msgs + msg operation_ref 135685 // "pull()" + forward ranks 6 "1.1.2.1.1" dirscanvas_ref 131845 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 7 "1.1.2.1.1.1" dirscanvas_ref 131973 + msgs + msg operation_ref 135813 // "fetch()" + forward ranks 8 "1.1.2.1.1.1.1" dirscanvas_ref 132101 + msgs + explicitmsg "fetch" + forward ranks 9 "1.1.2.1.1.1.1.1" dirscanvas_ref 132229 + no_msg + msgsend + msgsend + msgsend + msgsend + msgsend + msgsend + msgsend + msg operation_ref 135941 // "allocateBuffer()" + forward ranks 10 "2" dirscanvas_ref 132997 + msgs + msg operation_ref 135941 // "allocateBuffer()" + forward ranks 11 "2.1" dirscanvas_ref 131717 + msgs + explicitmsg "allocateNewFrame" + forward ranks 12 "2.1.1" dirscanvas_ref 132229 + no_msg + msgsend + msgsend + msg operation_ref 136069 // "process()" + backward ranks 13 "3" dirscanvas_ref 130693 + no_msg + msg operation_ref 136197 // "releaseBuffer()" + forward ranks 14 "4" dirscanvas_ref 133765 + msgs + explicitmsg "releaseFrame" + forward ranks 15 "4.1" dirscanvas_ref 132229 + no_msg + msgsend + msg operation_ref 136069 // "process()" + backward ranks 16 "5" dirscanvas_ref 130309 + no_msg + msg operation_ref 136325 // "isCalculated()" + forward ranks 17 "6" dirscanvas_ref 131717 + msgs + explicitmsg "isCalculatedFrame" + forward ranks 18 "6.1" dirscanvas_ref 132229 + no_msg + msgsend + msg operation_ref 136197 // "releaseBuffer()" + forward ranks 19 "7" dirscanvas_ref 134149 + msgs + explicitmsg "releaseFrame" + forward ranks 20 "7.1" dirscanvas_ref 132229 + no_msg + msgsend +msgsend +end diff --git a/uml/lumiera/132357.diagram b/uml/lumiera/132357.diagram new file mode 100644 index 000000000..5a7ffa76a --- /dev/null +++ b/uml/lumiera/132357.diagram @@ -0,0 +1,172 @@ +format 40 + +classcanvas 128133 class_ref 143493 // OperationBase + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 232 13 2000 + end +classcanvas 128261 class_ref 143621 // QueryCache + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 186 252 2000 + end +classcanvas 128517 class_ref 143877 // ReadSource + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 297 165 2000 + end +classcanvas 130309 class_ref 144005 // BuffTable + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 100 508 2000 + end +classcanvas 130437 class_ref 142725 // WiringDescriptor + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 82 319 2005 + end +classcanvas 130565 class_ref 144133 // BuffHandle + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 169 563 2000 + end +textcanvas 131461 "const" + xyzwh 101 388 2010 29 18 +classcanvas 131717 class_ref 144261 // Invocation + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + color lightorange + xyz 31 439 2000 + end +classcanvas 131845 class_ref 143365 // NodeWiring + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 222 423 2005 + end +classcanvas 131973 class_ref 142597 // StateAdapter + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 25 230 2005 + end +classcanvas 132357 class_ref 144389 // ProcessData + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 186 140 2015 + end +classcanvas 132997 class_ref 144517 // Strategy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 199 319 3010 + end +classcanvas 133253 class_ref 144517 // Strategy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 301 301 2005 + end +classcanvas 134021 class_ref 144645 // FeedCache + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 190 80 2010 + end +classcanvas 134533 class_ref 144389 // ProcessData + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 238 125 2004 + end +classcanvas 134661 class_ref 144517 // Strategy + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 250 309 3005 + end +textcanvas 137477 "as configured" + xyzwh 308 376 3010 68 18 +classcanvas 137733 class_ref 143749 // PullInput + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 194 198 2010 + end +classcanvas 137861 class_ref 143749 // PullInput + draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default + xyz 247 184 2005 + end +textcanvas 139781 "Policy Classes" + xyzwh 163 50 2005 81 21 +relationcanvas 130693 relation_ref 150405 // + geometry VHr + from ref 130309 z 1999 stereotype "<>" xyz 177 517 3000 to point 203 536 + line 130821 z 1999 to ref 130565 + no_role_a no_role_b + multiplicity_a_pos 211 537 3000 no_multiplicity_b +relationcanvas 130949 relation_ref 150533 // + from ref 130309 z 1999 to ref 130437 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 132229 relation_ref 149509 // + from ref 131845 z 2004 to point 219 401 + line 137605 z 2004 to point 162 401 + line 137221 z 2004 to ref 130437 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 133381 relation_ref 151301 // + from ref 133253 z 1999 to point 333 274 + line 137349 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135685 relation_ref 152197 // + from ref 131717 z 1999 to ref 131973 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135813 relation_ref 152325 // + from ref 131717 z 1999 to ref 130437 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135941 relation_ref 152453 // + geometry VH + from ref 131717 z 1999 to point 63 536 + line 137093 z 1999 to ref 130309 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 136069 relation_ref 152581 // + from ref 131845 z 2004 to ref 132997 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 136197 relation_ref 152709 // + from ref 131845 z 2004 to ref 134661 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 136325 relation_ref 152837 // + from ref 131845 z 2004 to ref 133253 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 136453 relation_ref 152965 // + from ref 131845 z 1999 stereotype "<>" xyz 145 441 3000 to ref 131717 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 137989 relation_ref 153093 // + from ref 132997 z 1999 to point 222 316 + line 139653 z 1999 to ref 128261 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138117 relation_ref 153221 // + from ref 128261 z 1999 to ref 137733 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138245 relation_ref 153349 // + from ref 137733 z 2009 to ref 132357 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138373 relation_ref 153477 // + from ref 132357 z 2009 to ref 134021 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138501 relation_ref 153605 // + geometry VHV unfixed + from ref 134021 z 1999 to point 223 68 + line 138885 z 1999 to point 275 68 + line 139013 z 1999 to ref 128133 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138629 relation_ref 153733 // + geometry VHV unfixed + from ref 128517 z 1999 to point 333 68 + line 139141 z 1999 to point 275 68 + line 139269 z 1999 to ref 128133 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 138757 relation_ref 153861 // + from ref 134533 z 1999 to ref 128133 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 139397 relation_ref 153989 // + from ref 134661 z 2004 to ref 137861 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 139525 relation_ref 154117 // + from ref 137861 z 2003 to ref 134533 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +end diff --git a/uml/lumiera/5.session b/uml/lumiera/5.session index fc9677d8c..3de151827 100644 --- a/uml/lumiera/5.session +++ b/uml/lumiera/5.session @@ -1,14 +1,33 @@ -window_sizes 1140 830 270 860 680 71 +window_sizes 1302 1004 270 1022 854 71 diagrams - active componentdiagram_ref 128005 // Overview - 702 640 80 4 2 0 + classdiagram_ref 131973 // Render Mechanics + 407 690 100 4 2 0 + collaborationdiagram_ref 132229 // Render Process + 825 684 100 4 0 0 + active classdiagram_ref 132357 // StateAdapter composition + 414 658 100 4 0 0 end show_stereotypes selected - package_ref 129 // lumiera +package_ref 129 // lumiera open - componentview_ref 128133 // interfaces - classview_ref 128005 // Session + class_ref 132741 // State + +package_ref 129029 // Controller + class_ref 131717 // ProcNode + class_ref 142469 // StateProxy + class_ref 142597 // StateAdapter + class_ref 142725 // WiringDescriptor + class_ref 143365 // NodeWiring + class_ref 143621 // QueryCache + class_ref 143749 // PullInput + class_ref 143877 // ReadSource + class_ref 144389 // ProcessData + class_ref 144645 // FeedCache + class_ref 144517 // Strategy + class_ref 144005 // BuffTable + class_ref 144261 // Invocation + usecaseview_ref 128005 // Renderengine Use class_ref 140677 // QueryHandler class_ref 140805 // TypeHandler class_ref 140933 // ResolverBase diff --git a/uml/lumiera/lumiera.prj b/uml/lumiera/lumiera.prj index dcdd63301..a533da6cc 100644 --- a/uml/lumiera/lumiera.prj +++ b/uml/lumiera/lumiera.prj @@ -1,6 +1,6 @@ format 40 "lumiera" - revision 44 + revision 48 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/index.html b/wiki/index.html index 2c34a10d1..d84708d1a 100644 --- a/wiki/index.html +++ b/wiki/index.html @@ -942,7 +942,7 @@ git push git://git.pipapo.org/lumiera/mob lumiera/mob is an anonymous account at pipapo.org where everyone can commit changes. -
    +
    We keep a protocol or short summary of each important discussion. The summaries of the monthly developer meetings are posted to the Mailinglist and can be found on pipapo.org too
 
 * [[05-08 developer meeting 8.May.2008|IRC_2008-05-08]]
@@ -950,7 +950,9 @@ lumiera/mob is an anonymous account at pipapo.org where everyone can commit chan
 * [[03-08 developer meeting 6.Mar.2008|IRC_2008-03-06]]
 * [[1.official developer meeting 1.Feb.2008|IRC_2008-02-01]]
 * [[informal developer meeting 10.Aug.2007|IRC_2007-08-10]]
-
    + +!talks about specific topics +* [[buffer allocation for render nodes (6/08)|IRC_log_BufferAllocation_2008-06]] 
    !10/11 aug 2007
@@ -1588,6 +1590,137 @@ Ichthyo explains that the builder needs to detect cycles and check if the high l
 Next meeting is on thursday 5th June 21:00 UTC
    +
    +
    ! 5.June 2008 on #lumiera
+__cehteh__ and __ichthyo__
+{{{
+[2008-06-05 19:21:21] <cehteh> do you need me? .. i am away if not .. i have no much to say for the today meeting either
+[2008-06-05 19:21:57] <ichthyo> I have one topic I want to discuss with you, cehteh
+[2008-06-05 19:22:07] <ichthyo> but it need not be now, or in the meeting
+[2008-06-05 19:22:07] <cehteh> ok
+[2008-06-05 19:22:24] <ichthyo> it's about allocating processing buffers 
+[2008-06-05 19:23:20] <cehteh> the backend will provide them as temporary files/cyclic buffers
+[2008-06-05 19:23:52] <cehteh> its not there yet but in my mind
+[2008-06-05 19:24:11] <ichthyo> haha, same for the builder... it's mostly just in my mind
+[2008-06-05 19:24:42] <cehteh> opened almost like a normal file but giving frame properties instead filename
+[2008-06-05 19:24:56] <cehteh> (there will be a distinct api for that)
+[2008-06-05 19:25:01] <ichthyo> ok
+[2008-06-05 19:25:05] <ichthyo> regarding the buffers: my question is more special
+[2008-06-05 19:25:19] <ichthyo> if you want to cache a frame (intermediary result)
+[2008-06-05 19:25:35] <ichthyo> then I thought we could avoid the copy operation
+[2008-06-05 19:25:44] <ichthyo> I could arrange things accordingly
+[2008-06-05 19:25:46] <cehteh> then the backend creates a backing mmaped file for that maybe manages its size (or do you want to tell how much frames you want to cache?)
+[2008-06-05 19:26:06] <cehteh> yes perfect .. thats what i am planning
+[2008-06-05 19:26:26] <ichthyo> you know, many processing nodes will be able to process "in place"
+[2008-06-05 19:26:34] <ichthyo> but ther are some that can't do this
+[2008-06-05 19:27:44] <ichthyo> so basically each processing function will "see" input frame buffer(s) and output frame buffer(s). but when a node is "in-place-capable", actually the in and out buffer may point to the same location
+[2008-06-05 19:26:55] <cehteh> basiically all temporary frames with the same properties are allcoated from the same backing file (well maybe 2 caching levels but not important here)
+[2008-06-05 19:27:06] <cehteh> the index give them meaning
+[2008-06-05 19:27:49] <cehteh> do you can query (and lock) a frame by that
+[2008-06-05 19:28:04] <ichthyo> that sounds good
+[2008-06-05 19:28:24] <cehteh> do some inplace editing and then tell the backend "this is now frame N of node X"
+[2008-06-05 19:28:34] <ichthyo> yeah, exactly
+[2008-06-05 19:28:44] <cehteh> (plus a uuid or preferably genertion number)
+[2008-06-05 19:28:39] <ichthyo> basically my Idea was as follows:
+[2008-06-05 19:29:47] <ichthyo> when I know the result will be cached, I'll let the node process into the location of the cache frame, and any node which will /use/ this frame as an input will be wired such that it isn't allowed to modify this frame (which is supposed to be located in the cache)
+[2008-06-05 19:30:45] <cehteh> yes thats managed in the index
+[2008-06-05 19:30:48] <ichthyo> for this to work, I need to "allocate and lock" a location in the cache, and release it when it contains the final processed result
+[2008-06-05 19:31:17] <cehteh> well i try to make no locks there, you query frames which are uniquely identified
+[2008-06-05 19:31:44] <ichthyo> it doesnt need to be a "lock
+[2008-06-05 19:31:55] <ichthyo> just some way to tell that this frame is "under construction"
+[2008-06-05 19:32:01] <cehteh> yes
+[2008-06-05 19:32:14] <cehteh> we thinking the same :)
+[2008-06-05 19:32:57] <cehteh> well problem is when shortly after that another node queries the source frame which got destructed .. thats something the builder needs to avoid, nothing i can do then
+[2008-06-05 19:33:21] <ichthyo> yes, builder will care for that
+[2008-06-05 19:33:41] <ichthyo> I can even tell in advance the maximum number of temporary buffers I need
+[2008-06-05 19:33:51] <cehteh> and it not only needs a under-construcion
+[2008-06-05 19:34:44] <cehteh> there are 2 indices one for source and one for destination
+[2008-06-05 19:35:11] <cehteh> indices will have a pointer to the 'job' working on it i tihnk
+[2008-06-05 19:35:24] <ichthyo> ok
+[2008-06-05 19:35:48] <cehteh> (actually there is a list planed many jobs can read-share an frame)
+[2008-06-05 19:36:40] <cehteh> i would like if I do not need to do *any* checks in that direction ... means the builder delivers clean jobs which dont step on their own foot
+[2008-06-05 19:36:54] <ichthyo> my understanding too
+[2008-06-05 19:37:07] <ichthyo> also, I want the nodes to be freed of any checks
+[2008-06-05 19:37:33] <ichthyo> so they can assume they get a valid buffer pointer to the right sort of buffer
+[2008-06-05 19:37:54] <cehteh> yes thats guranteed
+[2008-06-05 19:37:41] <cehteh> if it fails then we get some hairy bugs ... but checking job dependencies afterwards is costly
+[2008-06-05 19:38:53] <ichthyo> I mean -- I want to prepare everything as much as possible while building, so that all that needs to be "filled in" when starting the processing are the actual buffer locations
+[2008-06-05 19:38:58] <cehteh> *thinkin* prolly easier than it looks
+[2008-06-05 19:39:10] <cehteh> exaxctly
+[2008-06-05 19:39:50] <ichthyo> we can't prepare everything, because, some nodes may include a variable ammount of source frames
+[2008-06-05 19:40:11] <ichthyo> and this number can depend on automation. Classic example is the "time average" video effect
+[2008-06-05 19:39:53] <cehteh> problem is only when the builder generates one node which takes X and in-place generates Y from it
+[2008-06-05 19:40:10] <cehteh> and you have a 2nd node which takes X too 
+[2008-06-05 19:40:23] <cehteh> this needs to be serialized somehow
+[2008-06-05 19:41:12] <ichthyo> regarding the problem you mention: I want to exclude/avoid this situation already when building
+[2008-06-05 19:41:35] <cehteh> yes thats what i was thinking .. thats easiest addressed there
+[2008-06-05 19:41:46] <cehteh> and a very ugly bug when it fails :(
+[2008-06-05 19:41:42] <ichthyo> when a node puts its result into a frame located within the cache
+[2008-06-05 19:41:59] <ichthyo> this frame is treated as if it is read-only
+[2008-06-05 19:42:21] <ichthyo> no node depending on this frame will be wired in a way that allows "in-place"
+[2008-06-05 19:42:33] <cehteh> about the time averaging: i plan to hint some dependencies so you can ask for "maybe" or by some priority depending on quality/whatever
+[2008-06-05 19:43:19] <cehteh> where quality should be runtime adjusted by the profiler
+[2008-06-05 19:43:39] <ichthyo> the problem with time averaging is: we don't know how much frames will be averaged at build time, because that's a automatable effect parameter
+[2008-06-05 19:43:47] <cehteh> thats a case where a dependencie might not be fullfilled .. but only on request
+[2008-06-05 19:44:08] <ichthyo> but the "quality" thing sounds like a good idea
+[2008-06-05 19:44:17] <cehteh> yes then split that rendering into 3 passes?
+[2008-06-05 19:44:27] <cehteh> 1st pass : building the graph
+[2008-06-05 19:44:53] <cehteh> 2nd pass: determine dependencies (by inspecting automation)
+[2008-06-05 19:45:00] <cehteh> 3rd pass: do the render
+[2008-06-05 19:45:10] <ichthyo> maybe?
+[2008-06-05 19:45:17] <ichthyo> 1st pass of course is clear
+[2008-06-05 19:45:25] <cehteh> well do you have a better idea?
+[2008-06-05 19:45:49] <cehteh> so far i thought about 2 pass where the dependency analysis was part of the builder
+[2008-06-05 19:46:02] <ichthyo> agreed
+[2008-06-05 19:46:28] <cehteh> but making it three pass shouldnt be a problem or?
+[2008-06-05 19:46:51] <ichthyo> I also thought after having finished the raw graph, I'll do some configuration calldown, e.g. to determine the maximum number of buffers needed
+[2008-06-05 19:46:59] <cehteh> maybe even adaptive 2/3 pass depending on effects ... but maybe that would complicate it unnecessary
+[2008-06-05 19:47:43] <ichthyo> its not really a problem, just need to be aware and work the details out correctlyy
+[2008-06-05 19:47:49] <cehteh> i dont think you need  to count the buffers (not yet, maybe i oversee soemthing)
+[2008-06-05 19:48:08] <cehteh> otherwise the backend should manage that automatically
+[2008-06-05 19:48:18] <ichthyo> yes, I'm fine with that
+[2008-06-05 19:48:46] <ichthyo> just to note, if it helps with the allocation, I /can/ tell the maximum number of buffers needed
+[2008-06-05 19:49:00] <ichthyo> (for a given segment of the graph, of course)
+[2008-06-05 19:49:09] <cehteh> not sure if i overseen something, but i think when needed such a 'configuration calldown' (and optimizing pass) could be added later
+[2008-06-05 19:49:27] <ichthyo> sure
+[2008-06-05 19:49:50] <cehteh> buffers itself doesnt cost .. but if you really need a lot it will cause IO
+[2008-06-05 19:49:57] <cehteh> but that unavoidable anyways
+[2008-06-05 19:50:05] <ichthyo> no no
+[2008-06-05 19:50:19] <cehteh> yes yes
+[2008-06-05 19:50:20] <ichthyo> I'll try to minimize buffer use as much as possible
+[2008-06-05 19:50:24] <cehteh> :)
+[2008-06-05 19:50:30] <cehteh> of course
+[2008-06-05 19:51:00] <cehteh> but there are always some limits on finite machines
+[2008-06-05 19:51:26] <ichthyo> the problematic case are usual rather rare corner cases, but it should handle those flawless, of course
+[2008-06-05 19:51:36] <ichthyo> similar for the size of the buffers
+[2008-06-05 19:51:46] <ichthyo> I dont want Lumiera to clip the image
+[2008-06-05 19:51:49] <ichthyo> as cinelerra does
+[2008-06-05 19:52:04] <ichthyo> e.g. when using the motion tracker
+[2008-06-05 19:52:20] <cehteh> well if you need safe-regions around you need to use biggier frames
+[2008-06-05 19:52:31] <cehteh> but memory requirements grow quadratic!
+[2008-06-05 19:52:46] <ichthyo> the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra
+[2008-06-05 19:52:59] <cehteh> yes agreed
+[2008-06-05 19:53:15] <ichthyo> I don't think we need safe-regions allways, 
+[2008-06-05 19:53:31] <ichthyo> but, as e.g. the motion tracking will create automation data in Lumiera
+[2008-06-05 19:53:38] <cehteh> yes only for some effect .. motion tracker doesnt need it
+[2008-06-05 19:53:50] <ichthyo> it means the actual buffer size depends on automation data for a given frame
+[2008-06-05 19:53:56] <cehteh> that just xyr transformation
+[2008-06-05 19:54:35] <cehteh> a blur is something which might require a small safe-region to bleed over the edges
+[2008-06-05 19:54:43] <ichthyo> yes, you are right
+[2008-06-05 19:54:52] <ichthyo> if the motion tracker is wired intelligently
+[2008-06-05 19:55:05] <ichthyo> it doesn't need to move anyting itself
+[2008-06-05 19:55:18] <cehteh> mapping the motion tracker transformation to a destionation might need safe regions
+[2008-06-05 19:55:30] <cehteh> (in case of rotations)
+[2008-06-05 19:55:36] <ichthyo> yes agreed
+[2008-06-05 19:56:16] <cehteh> well temp buffers will be allcocated for frames of the same 'class' i aleready saied that
+[2008-06-05 19:56:50] <cehteh> and i will group these classes so that some similar sizes fall in the same class 
+[2008-06-05 19:57:19] <cehteh> that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in
+[2008-06-05 19:57:32] <cehteh> the kernel will do that automatically for us
+[2008-06-05 19:57:37] <ichthyo> :)
+[2008-06-05 19:57:59] <cehteh> well mostly .. i need to whip it with the right hints ;)
+[2008-06-05 19:58:10] <ichthyo> :-o
+}}}
    +
    /***
 ''InlineJavascriptPlugin for ~TiddlyWiki version 1.2.x and 2.0''
diff --git a/wiki/renderengine.html b/wiki/renderengine.html
index 9caeef51c..a2f27a13f 100644
--- a/wiki/renderengine.html
+++ b/wiki/renderengine.html
@@ -556,10 +556,11 @@ is how to implement the relationship between [[MObject]]s and Assets. Do we use
    -
    +
    Assets are created by a Factories returning smart pointers; the Asset creation is bound to specific use cases and //only available// for these specific situations. There is no generic Asset Factory.
 
-For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file)
    +For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file &rarr; LoadingMedia) + 
    The Asset Manager provides an Interface to some internal Database holding all Assets in the current Session and System state. It may be a real Database at some point (and for the moment it's a Hashtable). Each [[Asset]] is registered automatically with the Asset Manager; it can be queried either by it's //identification tuple// or by it's unique ID.
    @@ -589,6 +590,9 @@ Attachment on itself does //not// keep an object alive. Rather, it's a direct re [img[how to implement Automation|uml/fig129669.png]]
    +
    +
    While generally automation is treated as a function over time, defining and providing such a function requires some //Automation Data.// The actual layout and meaning of this data is deemed an implementation detail of the [[parameter provider|ParamProvider]] used, but nevertheless an automation data set has object characteristics within the [[EDL (high-level-model)|EDL]], allowing it to be attached, moved and [[placed|Placement]] by the user.
    +
    Starting out from the concepts of Objects, Placement to Tracks, render Pipes and connection properties (&rarr; see [[here|TrackPipeEDL]]) within the EDL, we can identify the elementary operations occuring within the Builder. Overall, the Builder is organized as application of //visiting tools// to a collection of objects, so finally we have to consider some object kind appearing in the working function of the given builder tool, which holds at this moment some //context//. The job now is to organize this context such as to create a predictable build process from this //event driven// approach.
 &rarr;see also: BuilderPrimitives for the elementary situations used to cary out the building operations
@@ -740,11 +744,11 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 }
 //}}}
    -
    +
    All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actual performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &mdash; to pay in the Builder &mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
 
 [>img[Outline of the Build Process|uml/fig129413.png]]
-The building itself will be broken down into several small tool application steps. Each of these steps has to be mapped to the MObjects found on the [[Timeline]]. Remember: the idea is that the so called "[[Fixture]]" contains only [[ExplicitPlacement]]s which in turn link to MObjects like Clips, Effects and Automation. So it is sufficient to traverse this list and map the build tools to the elements. Each of these build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
+The building itself will be broken down into several small tool application steps. Each of these steps has to be mapped to the MObjects found on the [[Timeline]]. Remember: the idea is that the so called "[[Fixture]]" contains only [[ExplicitPlacement]]s which in turn link to MObjects like Clips, Effects and [[Automation]]. So it is sufficient to traverse this list and map the build tools to the elements. Each of these build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
 * find the "Segments", i.e. the locations where the overall configuration changes
 * for each segment: generate a ProcNode for each found MObject and wire them accordingly
 Note, //we still have to work out how exactly building, rendering and playback work// together with the backend-design. The build process as such doesn't overly depend on these decisions. It is easy to reconfigure this process. For example, it would be possible as well to build for each frame separately (as Cinelerra2 does), or to build one segment covering the whole timeline (and handle everything via [[Automation]]
@@ -760,7 +764,31 @@ Note, //we still have to work out how exactly building, rendering and playback w
 [img[Colaborations in the Build Process|uml/fig128517.png]]
    -
    +
    +
    Actually setting up and wiring a [[processing node|ProcNode]] involves several issues and is carried out at the lowest level of the build process.
+It is closely related to &rarr; [[the way nodes are operated|NodeOperationProtocol]] and the &rarr; [[mechanics of the render process|RenderMechanics]]
+
+!!!object creation
+The Nodes are small polymorphic objects, carrying configuration data, but no state. They are [[specially allocated|ManagementRenderNodes]], and the object creation is accessible by means of the NodeFactory solely. They //must not be deallocated manually.// The decision of what concrete node type to create depends on the actual build situation and is worked out by the combination of [[mould|BuilderMould]] and [[processing pattern|ProcPatt]] at the current OperationPoint, issuing a call to one of NodeFactory's {{{operator()}}}
+
+!!!node, plugin and processing function
+Its a good idea to distinguish clearly between those concepts. A plugin is a piece of (possibly external) code we use to carry out operations. We have to //discover its properties and capabilities.// We don't have to discover anything regarding nodes, because we (Lumiera builder and renderengine) are creating, configuring and wiring them to fit the specific purpose. Both are to be distinguished from processing functions, which do the actual calculations on the media data. Every node typically encompasses at least one processing function, which may be an internal function in the node object, a library function from Lumiera or GAVL, or external code loaded from a plugin.
+
+!!!node interfaces
+As a consequence of this distinctions, in conjunction with a processing node, we have to deal with three different interfaces
+* the __build interface__ is used by the builder to set up and wire the nodes. It can be full blown C++ (including templates)
+* the __operation interface__ is used to run the calculations, which happens in cooperation of Proc-Layer and Backend. So a function-style interface is preferable.
+* the __inward interface__ is accessed by the processing function in the course of the calculations to get at the necessary context, including in/out buffers and param values.
+
+!!!wiring data connections
+A node //knows its predecessors, but not its successors.// When being //pulled//&nbsp; in operation, it can expect to get a frame provider for accessing the in/out buffer locations (some processing functions may be "in-place capable", but that's only a special case of the former). At this point, the ''pull principle'' comes into play: the node may request input frames from the frame provider, passing its predecessors as a ''continuation''.
+With regard to the build process, the wiring of data connections translates into providing the node with its predecessors and preconfiguring the possible continuations. While in the common case, a node has just one input/output and pulls from its predecessor a frame for the same timeline position, the general case can be more contrived. A node may process N buffers in parallel and may require several different time positions for it's input, even at a differing framerate. So the actual source specification is (predNode,time,frameType). The objective of the wiring done in the build process is to factor out the parts known in advance, while in the render process only the variable part need to be filled in. Or to put it differently: wiring builds a higher order function (time)->(continuation), where continuation can be invoked to get the desired input frame.
+
+!!!wiring control conections
+In many cases, the parameter values provided by these connections aren't frame based data, rather, the processing function needs a call interface to get the current value (value for a given time), which is provided by the parameter object. Here, the wiring needs to link to the suitable parameter instance, which is located within the high-level model (!). As an additional complication, calculating the actual parameter value may require a context data frame (typically for caching purposes to speed up the interpolation). While these parameter context data frames are completely opaque for the render node, they have to be passed in and out similar to the state needed by the node itself, and the wiring has to prepare for accessing these frames too.
+
    +
    +
    The Builder takes some MObject/[[Placement]] information (called Timeline) and generates out of this a Render Engine configuration able to render this Objects. It does all decisions and retrieves the current configuration of all objects and plugins, so the Render Engine can just process them stright forward.
 
 The Builder is the central part of the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]
@@ -772,7 +800,7 @@ As the builder has to create a render node network implementing most of the feat
 * //operating the Builder// can be viewed at from two different angles, either emphasizing the [[basic building operations|BasicBuildingOperations]] employed to assemble the render node network, or focussing rather at the [[mechanics|BuilderMechanics]] of cooperating parts while processing.
 * besides, we can identify a small set of elementary situations we call [[builder primitives|BuilderPrimitives]], to be covered by the mentioned BuilderToolKit; by virtue of [[processing patterns|ProcPatt]] they form an [[interface to the rule based configuration|BuilderRulesInterface]].
 * the actual building (i.e. the application of tools to the timeline) is done by the [[Assembler|BuilderAssembler]], which is basically a collection of functions (but has a small amount of global configuration state)
-* any non-trivial wiring of render nodes, tracks, pipes and automation is done by the services of the [[connection manager|ConManager]]
+* any non-trivial wiring of render nodes, tracks, pipes and [[automation|Automation]] is done by the services of the [[connection manager|ConManager]]
    @@ -784,13 +812,14 @@ As the builder has to create a render node network implementing most of the feat !!pattern of operation The working pattern of this builder mechanics can be described as triggering, enqueuing, priorizing, recursing and exhausting. Without the priorizing part, it would be a depth-first call graph without any context state, forcing us to have all cross reference information available at every node or element to be treated. We prefer to avoid this overhead by ordering the operations into several phases and within these phases into correlated entities with the help of a ''weighting function'' and scheduling with a ''priority queue''
    -
    +
    The [[Builder]] uses different kinds of tools for creating a network of render nodes from a given high-level model. When breaking down this (necessarily complex) process into small manageable chunks, we arrive at [[elementary building situations|BuilderPrimitives]]. For each of these there is a specialized tool. We denote these tools as "moulds" because they are a rather passive holder for the objects to be attached and wired up. They are shaped according to the basic form the connections have to follow for each of these basic situations:
 * attaching an effect to a pipe
 * combining pipes via a transition
 * starting out a pipe from a source reader
 * general connections from the exit node of a pipe to the port of another pipe
-In all those cases, the active part is provided by [[processing patterns|ProcPatt]] &mdash; sort of micro programs executed within the context of a given mould: the processing pattern defines the steps to take (in the standard/basic case this is just "attach"), while the mould holds and provides the location where these steps will operate.
    +In all those cases, the active part is provided by [[processing patterns|ProcPatt]] &mdash; sort of micro programs executed within the context of a given mould: the processing pattern defines the steps to take (in the standard/basic case this is just "attach"), while the mould holds and provides the location where these steps will operate. Actually, this location is represented as a OperationPoint, provided by the mould and abstracting the details of making multi-channel connections. + 
    While assembling and building up the render engines node network, a small number of primitive building situations is encountered repeatedly. The BuilderToolKit provides a "[[mould|BuilderMould]]" for each of these situations, typically involving parametrisation and the application of a [[processing pattern|ProcPatt]].
@@ -863,16 +892,12 @@ While building, the application of such a visiting tool (especially the [[NodeCr
    -
    +
    Besides the primary working tool within the builder (namely the [[Node Creator Tool|PlanningNodeCreatorTool]]), on a lower level, we encounter several [[elementary building situations|BuilderPrimitives]] &mdash; and for each of these elementary situations we can retrieve a suitable "fitting tool" or [[mould|BuilderMould]]. The palette of these moulds is called the ''tool kit'' of the builder. It is subject to configuration by rules.
 
-!! {{red{open questions}}}
-* how to address these moulds
-* how to type them
-* how to parametrize them
 
 !!addressing a mould
-All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type ({{{PipeMould}}}, {{{CombiningMould}}}, {{{SourceChainMould}}}, {{{WiringMould}}}) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
+All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type (PipeMould, CombiningMould, SourceChainMould, WiringMould) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
 
 !!configuring a mould
 As each mould kind is different, it has a {{{prepare(...)}}} function with suitably typed parameters. The rest is intended to be  self-configuring (for example, a ~CombiningMould will detect the actual kind of Transition and select the internal mode of operation), so that it's sufficient to just call {{{operate()}}}
@@ -880,15 +905,18 @@ As each mould kind is different, it has a {{{prepare(...)}}} function with suita
 !!sequence of operations
 When {{{operate()}}} doesn't throw, the result is a list of //successor moulds// &mdash; you shouldn't use the original mould after triggering its operation, because it may have been retracted as a result and reused for another purpose by the tool factory. It is not necessary to store these resulting moulds either (as they can be retrieved as described above), but they can be used right away for the next building step if applicable. In the state they are returned from a successful building step (mould operation = execution of a contained [[processing pattern|ProcPatt]]), they are usually already holding a reference to the part of the network just created and need to be configured only with the next high-level object (effect, placement, pipe, processing pattern or similar, depending on the concrete situation) in order to carry out the next step.
 
-&rarr;see also: BuilderPrimitives for the elementary working situations corresponding to these fitting tools
+!!single connection step
+at the lowest level within the builder there is the step of building a //connection.// This step is executed by the processing pattern with the help of the mould. Actually, making such a connection is more complicated, because in the standard case it will connect N media streams simultaneously (N=2 for stereo sound or 3D video, N=6 for 5.1 Surround, N=9 for 2nd order Ambisonics). These details are encapsulated within the OperationPoint, which is provided by the mould and exhibits a common interface for the processing pattern to express the connecting operation.
+
+&rarr;see also: BuilderPrimitives for the elementary working situations corresponding to each of these [[builder moulds|BuilderMould]]
    -
    +
    Background: #fefefd
 Foreground: #000
 PrimaryPale: #8fb
-PrimaryLight: #50d2ae
-PrimaryMid: #1b9989
+PrimaryLight: #4dc9a7
+PrimaryMid: #16877a
 PrimaryDark: #0f3f56
 SecondaryPale: #ffc
 SecondaryLight: #fe8
@@ -900,6 +928,15 @@ TertiaryMid: #99a
 TertiaryDark: #667
 Error: #f88
    +
    +
    The Connection Manager is a __Facade__ for querying information and deriving decisions regarding various aspects of data streams and possible connections.
+* retrieve information about capabilities of a stream type given by ID
+* decide if a connection is possible
+* retrieve a //strategy// for implementing a connection
+
+In the intended implementation, a good deal of this functionality will actually be implemented by [[rules|ConfigRules]], while other parts need to be provided by hard wired logic, at least as a fallback. Anyway, the purpose of the Connection Manager ois to isolate the [[Builder]], which is client of this information and decision services, from these details
+
    +
    Configuration Queries are requests to the system to "create or retrieve an object with //this and that // capabilities". They are resolved by a rule based system ({{red{planned feature}}}) and the user can extend the used rules for each Session. Syntactically, they are stated in ''prolog'' syntax as a conjunction (=logical and) of ''predicates'', for example {{{stream(mpeg), pipe(myPipe)}}}. Queries are typed to the kind of expected result object: {{{Query<Pipe> ("stream(mpeg)")}}} requests a pipe excepting/delivering mpeg stream data &mdash; and it depends on the current configuration what "mpeg" means. If there is any stream data producing component in the system, which advertises to deliver {{{stream(mpeg)}}}, and a pipe can be configured or connected with this component, then the [[defaults manager|DefaultsManagement]] will create/deliver a [[Pipe|PipeHandling]] object configured accordingly.
 &rarr; [[Configuration Rules system|ConfigRules]]
@@ -991,7 +1028,7 @@ This is an very important external Interface, because it links together all thre
 
    [[ProcLayer and Engine]]
    -
    +
    As detailed in the [[definition|DefaultsManagement]], {{{default(Obj)}}} is sort of a Joker along the lines "give me a suitable Object and I don't care for further details". Actually, default objects are implemented by the {{{mobject::session::DefsManager}}}, which remembers and keeps track of anything labeled as "default". This defaults manager is a singleton and can be accessed via the [[Session]] interface, meaning that the memory track regarding defaults is part of the session state. Accessing an object via the query for an default actually //tagges// this object (storing a weak ref in the ~DefsManager). Alongside with each object successfully queried via "default", the degree of constriction is remembered, i.e. the number of additional conditions contained in the query. This enables us to search for default objects starting with the most unspecific.
 
 !Skeleton
@@ -1011,7 +1048,7 @@ Taken precisely, the "degree of constriction" yields only a partial or
 {{red{WARN}}} there is an interference with the (planned) Undo function. This is a general problem of the config queries; just ignoring this issue seems reasonable.
 
 !!!Problems with the (preliminary) mock implementation
-As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see {{{MockConfigQuery}}}). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
+As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see MockConfigQuery). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
    @@ -1021,7 +1058,7 @@ As we don't have a Prolog interpreter on board yet, we utilize a mock store with {{{default(Obj)}}} is a predicate expressing that the object {{{Obj}}} can be considered the default setup under the given conditions. Using the //default// can be considered as a shortcut for actually finding a exact and unique solution. The latter would require to specify all sorts of detailed properties up to the point where only one single object can satisfy all conditions. On the other hand, leaving some properties unspecified would yield a set of solutions (and the user code issuing the query had to provide means for selecting one soltution from this set). Just falling back on the //default// means that the user code actually doesn't care for any additional properties (as long as the properties he //does// care for are satisfied). Nothing is said specifically on //how//&nbsp; this default gets configured; actually there can be rules //somewhere,// and, additionally, anything encountered once while asking for a default can be re-used as default under similar circumstances. &rarr; [[implementing defaults|DefaultsImplementation]]
    -
    +
    Along the way of working out various [[implementation details|ImplementationDetails]], decisions need to be made on how to understand the different facilities and entities and how to tackle some of the problems. This page is mainly a collection of keywords, summaries and links to further the discussion. And the various decisions should allways be read as proposals to solve some problem at hand...
 
 ''Everything is an object'' &mdash; of course, that's a //no-brainer // todays. Rather, important is what is not "an object", meaning it can't be arranged arbitrarily
@@ -1034,10 +1071,10 @@ We ''separate'' processing (rendering) and configuration (building). We have a [
 ''Objects are [[placed|Placement]] rather'' than assembled, connected, wired, attached. This is more of a rule-based approach and gives us one central metaphor and abstraction, allowing us to treat everything in an uniform manner. You can place it as you like, and the builder tries to make sense out of it, silently disabling what doesn't make sense.
 An [[EDL]] is just a collection of configured and placed objects (and has no additional, fixed structure). [[Tracks|Track]] form a mere organisational grid, they are grouping devices not first-class entities (a track doesn't "have" a pipe or "is" a video track and the like; it can be configured to behave in such manner by using placements though). [[Pipes|Pipe]] are hooks for making connections and are the only facility to build processing chains. We have global pipes, and each clip is built around a lokal [[source port|ClipSourcePort]] &mdash; and that's all. No special "media viewer" and "arranger", no special role for media sources, no commitment to some fixed media stream types (video and audio). All of this is sort of pushed down to be configuration, represented as asset of some kind. For example, we have [[processing pattern|ProcPatt]] assets to represent the way of building the source network for reading from some media file (including codecs treated like effect plugin nodes)
 
-''State'' is rigorously ''externalized'' and operations are to be ''scheduled'', to simplify locking and error handling. State is either treated similar to media stream data (as addressable and cacheable data frame), or is represented as "parameter" to be served by some [[parameter provider|ParamProvider]]. Automation is just another kind of parameter, i.e. a function, and how this function is calculated is an encapsulated implementation detail (we don't have "bezier automation", and then maybe a "linear automation", a "mask automation" and yet another way to handle transitions)
+''State'' is rigorously ''externalized'' and operations are to be ''scheduled'', to simplify locking and error handling. State is either treated similar to media stream data (as addressable and cacheable data frame), or is represented as "parameter" to be served by some [[parameter provider|ParamProvider]]. Consequently, [[Automation]] is just another kind of parameter, i.e. a function &mdash; how this function is calculated is an encapsulated implementation detail (we don't have "bezier automation", and then maybe a "linear automation", a "mask automation" and yet another way to handle transitions)
    -
    +
    This __proc-Layer__ and ~Render-Engine implementation started out as a design-draft by [[Ichthyo|mailto:Ichthyostega@web.de]] in summer 2007. The key idea of this 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.
 
 !Why doesn't the current Cinelerra-2 Design succeed?
@@ -1056,7 +1093,7 @@ As always, the main goal is //to cut down complexity// by the usual approach to
 
 To achieve this, here we try to separate ''Configuration'' from ''Processing''. Further, in Configuration we try to separate the ''high level view'' (users view when editing) from the ''low level view'' (the actual configuration effective for the calculations). Finally, we try to factor out and encapsulate ''State'' in order to make State explicit.
 
-The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render pipeline should process Video/Audio and do nothing else. All decisions, tests and conditional operations are factored out of the render process and handled as configuration of the pipeline, which is done by the Builder. The actual color model and number of ports is configured in by a pre-built wiring descriptor. All Nodes are of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. OpenGL and renderfarm support can be configured in as an alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering. We introduce separate control data connections for the automation data, separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes are using the same automation data).
+The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render pipeline should process Video/Audio and do nothing else. All decisions, tests and conditional operations are factored out of the render process and handled as configuration of the pipeline, which is done by the Builder. The actual color model and number of ports is configured in by a pre-built wiring descriptor. All Nodes are of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. OpenGL and renderfarm support can be configured in as an alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering. We introduce separate control data connections for the [[automation data|Automation]], separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or the case of two nodes using the same automation data).
 
 Another pertinent theme is to make the basic building blocks simpler, while on the other hand gaining much more flexibility for combining these building blocks. For example we try to unfold any "internal-multi" effects into separate instances (e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks. Similarly, we treat the Objects in the EDL in a more uniform manner and gain the possibility to [[place|Placement]] them in various ways.
    @@ -1101,16 +1138,17 @@ Basically, each elementary operation has to record the informations necessary to {{red{to be defined in more detail later...}}}
    -
    +
    The &raquo;Timeline&laquo; is a sequence of ~MObjects -- here clips -- together with an ExplicitPlacement, locating each clip at a given time and track. (Note: I simplified the time format and wrote frame numbers to make it more clear)
 [img[Example1: Objects in the EDL/Fixture|uml/fig128773.png]]
 
 ----
 After beeing processed by the Builder, we get the following Render Engine configuration
+{{red{note: please take this only as a "big picture", the implementation details got a lot more complicated as of 6/08}}}
 [img[Example1: generated Render Engine|uml/fig129029.png]]
    -
    +
    {{red{TODO: seemingly this example is slightly outdated, as the implementation of placements is now indirect via LocatingPin objects}}}
 This Example showes the //high level// EDL as well. This needs to be transformed into a Fixture by some facility still to be designed. Basically, each [[Placement]] needs to be queried for this to get the corresponding ExplicitPlacement. The difficult part is to handle possible Placement constraints, e.g. one clip can't be placed at a timespan covered by another clip on the same track. In the current Cinelerra2, all of this is done directly by the GUI actions.
 
@@ -1120,6 +1158,7 @@ The &raquo;Timeline&laquo; is a sequence of ~MObjects -- note: using the
 ----
 After beeing processed by the Builder, we get a Render Engine configuration.<br>
 It has to be segmented at least at every point with changes in the configuration, but some variations are possible, e.g. we could create a Render Engine for every Frame (as Cinelerra2 does) or we could optimize out some configurations (for example the effect extended beyond the end of the clip)
+{{red{note: as of 6/08 this can be taken only as the "big picture". Implementation will differ in details, and is more complicated than showed here}}}
 [img[Example2: generated Render Engine|uml/fig129157.png]]
    @@ -1701,7 +1740,7 @@ From experiences with other middle scale projects, I prefer having the test code [img[Example: Interfaces/Namespaces of the ~Session-Subsystems|uml/fig130053.png]]
    -
    +
    Opening and accessing media files on disk poses several problems, most of which belong to the domain of Lumiera's data backend. Here, we focus on the questions related to making media data available to the EDL and the render engine. Each media will be represented by an MediaAsset object, which indeed could be a compound object (in case of MultichannelMedia). Building this asset object thus includes getting informations from the real file on disk. For delegating this to the backend, we use the following query interface:
 * {{{queryFile(char* name)}}} requests accessing the file and yields some (opaque) handle when successful.
 * {{{queryChannel(fHandle, int)}}} will then be issued in sequence with ascending index numbers, until it returns {{{NULL}}}.
@@ -1712,7 +1751,9 @@ From experiences with other middle scale projects, I prefer having the test code
 
 {{red{to be defined in more detail later...}}}
 
-{{red{how to create a test stub for this interface...?}}}
    +&rarr; see "~MediaAccessFacade" for a (preliminary) interface definitioin +&rarr; see "~MediaAccessMock" for a mock/test implementaion + 
    Used to actually implement the various kinds of [[Placement]] of ~MObjects. ~LocatingPin is the root of a hierarchy of different kinds of placing, constraining and locating a Media Object. Basically, this is an instance of the ''state pattern'': The user sees one Placement object with value semantics, but when the properties of the Placement are changed, actually a ~LocatingPin object (or rather a chain of ~LocatingPins) is changed within the Placement. Subclasses of ~LocatingPin implement different placing/constraining behaviour:
@@ -1771,6 +1812,12 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 {{red{let's see if this approach works...}}}
    +
    +
    Contrary to the &rarr;[[Assets and MObjects|ManagementAssetRelation]], the usage pattern for [[render nodes|ProcNode]] is quite simple: All nodes are created together every time a new segment of the network is being build and are all needed together until this segment is re-built, at which point they can be thrown away altogether. While it would be easy to handle the nodes automatically by smart-ptr (the creation is accessible only by use of the {{{NodeFactory}}} anyways), it //seems advisable to care for a bulk allocation/deallocation here.// The reason being not so much the amount of memory (which is expected to be moderate), but the fact, that the build process can be triggered repeatedly several times a second when tweaking the EDL, which could lead to fragmentation and memory pressure.
+
+__5/2008__: the allocation mechanism can surely be improved later, but for now I am going for a simple implementation based on keeping all nodes of one kind together in a vector. The list of possible node kinds is hard wired, allowing to generate the object holding a chunk of nodes for one segment, mostly relying on the runtime system for the management.
+
    +
    <!--{{{-->
 <link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml'/>
@@ -1778,9 +1825,11 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;">loading <b>Proc-Layer</b> devel doku<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>
    -
    +
    The Interface asset::Media is a //key abstraction// It ties together several concepts and enables to deal with them on the interfaces in a uniform manner. Besides, as every Asset kind it belongs rather to the bookkeeping view: an asset::Media holds the specific properties and parametrisation of the media source it stands for. Regarding the __inward interface__ &mdash; as used from within the [[EDL]] or the [[Render Nodes|ProcNode]], it is irrelevant if any given asset::Media object stands for a complete media source, just a clip taken from this source or if a placeholder version of the real media source is used instead.
 [img[Asset Classess|uml/fig130437.png]]
+
+&rarr; see also LoadingMedia
    @@ -1840,7 +1889,27 @@ So, when creating a clip out of such a compound media asset, the clip has to be 
    NodeCreaterTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the NodeCreaterTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the NodeCreaterTool creates and wires the necessary [[nodes|ProcNode]]
    -
    +
    +
    The [[nodes|ProcNode]] are wired to form a "Directed Acyclic Graph"; each node knows its predecessor(s), but not its successor(s).  The RenderProcess is organized according to the ''pull principle'', thus we find an operation {{{pull()}}} at the core of this process. There is no such thing as an "engine object" calling nodes iteratively or table driven, rather, the nodes themselves issue recursive calls to their predecessor(s). For this to work, we need the nodes to adhere to a specific protocol:
+# Node is pulled, with a StateProxy object as parameter (encapsulating the access to the frames or buffers)
+# Node may now access current parameter values, using the state accessible via the StateProxy
+# using it's //input-output descriptor,// the Node creates a StateAdapter wrapping the StateProxy for accessing the output to pull and probably the input needed to calculate this output
+# StateAdapter first tries to get the output frames from the Cache in the Backend. In case of failure, a {{{process()}}} call is prepared by generating {{{pull()}}} call(s) for the input
+# as late as possible, typically on return, these recursive pull-calls have allocated a buffer containing the input data.
+# after all input is ready and prior to the {{{process()}}} call, the output buffers will be allocated, either from the cache, or alternatively (if not caching) from the "parent" StateAdapter up the callstack.
+# after all buffers are available, the StateAdapter issues the {{{process()}}} call back to the originating node, which now may dereference the frame pointers and do its calculations
+# finally, when the {{{pull()}}} call returns, "parent" state originating the pull holds onto the buffers containing the calculated output result.
+some points to note:
+* the input descriptor is {{{const}}} and precalculated while building (remember another thread may call in parallel)
+* when a node is "inplace-capable", input and output buffer may actually point to the same location
+* but there is no guarantee for this to happen, because the cache may be involved (and we can't overwrite the contents of a cache frame)
+* generally, a node may have N inputs and M output frames, which are expected to be processed in a single call
+
+&rarr; the [["mechanics" of the render process|RenderMechanics]]
+&rarr; more fine grained [[implementation details|RenderImplDetails]]
+
    +
    +
    We have to consider carefully how to handle the Creation of new class instances. Because, when done naively, it can defeat all efforts of separating subsystems, or &mdash; the other extreme &mdash; lead to a //switch-on-typeID//  programming style. We strive at a solution somewhere in the middle by utilizing __Abstract Factories__ on Interface or key abstraction classes, but providing specialized overloads for the different use cases. So in each use case we have to decide if we want to create a instance of some general concept (Interface), or if we have a direct collaboration and thus need the Factory to provide a more specific sub-Interface or even a concrete type.
 
 !Object creation use cases
@@ -1851,7 +1920,8 @@ So, when creating a clip out of such a compound media asset, the clip has to be
 |mark selection as clip|asset::Clip, session::Clip, Placement with unspec. LocatingPin| doesn't add to EDL|
 |loading Plugin|asset::Effect| usually at program startup|
 |create Session|asset::Track, asset::Pipe| |
-&rarr; [[Creating and registering Assets|AssetCreation]]
+&rarr; [[creating and registering Assets|AssetCreation]]
+&rarr; [[loading media|LoadingMedia]]
 
 !![[MObjects|MObject]]
 |add media to EDL|asset::Clip, session::Clip, Placement with unspecified LocatingPin| creating whole-media clip on-the-fly |
@@ -1880,6 +1950,14 @@ But because I know the opinions on this topc are varying (users tend to be delig
 My proposed aproach is to treat OpenGL as a separate video raw data type, requiring separete and specialized [[Processing Nodes|ProcNode]] for all calculations. Thus the Builder could connect OpenGL nodes if it is possible to cover the whole render path for preview and fall back to the normal ~ProcNodes for all relevant renders
    +
    +
    A low-level abstraction within the [[Builder]] &mdash; it serves to encapsulate the details of making multi-channel connections between the render nodes: In some cases, a node can handle N channels internally, while in other cases we need to replicate the node N times and wire each channel individually.
+
+The operation point is provided by the current BuilderMould and used by the [[processing pattern|ProcPatt]] executing within this mould and conducting the current build step. The operation point's interface allows //to abstract//&nbsp; these details, as well as to //gain additional control//&nbsp; if necessary (e.g. addressing only one of the channels). The most prominent build instruction used within the processing patterns (which is the instruction {{{"attach"}}}) relies on the aforementioned //approach of abstracted handling,// letting the operation point determine automatically how to make the connection.
+
+This is possible because the operation point has been provided (by the mould) with informations about the media stream type to be wired, which, together with information accessible at the the [[render node interface|ProcNode]] and from the [[referred processing assets|ProcAsset]], with the help of the [[connection manager|ConManager]] allows to figure out what's possible and how to do the desired connections.
+
    +
    The Lumiera Processing Layer is comprised of various subsystems and can be separated into a low-level and a high-level part. At the low-level end is the [[Render Engine|OverviewRenderEngine]] which basically is a network of render nodes cooperating closely with the Backend Layer in order to carry out the actual playback and media transforming calculations. Whereas on the high-level side we find several different [[Media Objects|MObjects]] that can be placed into the [[EDL]], edited and manipulated. This is complemented by the [[Asset Management|Asset]], which is the "bookkeeping view" of all the different "things" within each [[Session|SessionOverview]].
 
@@ -1890,7 +1968,7 @@ There is rather strong separation between these two levels, and &mdash; <
 [img[Block Diagram|uml/fig128005.png]]
    -
    +
    Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configured Render Engine //for every// RenderProcess. Before doing so, it queries from the Session (or, to be more precise, from the [[Fixture]] within the current Session) all necessary Media Object Placement information. The [[Builder]] then derives from this information the actual assembly of [[Processing Nodes|ProcNode]] comprising the Render Engine. Thus:
  * the source of the build process is a sequence of absolute (explicit) [[Placements|Placement]] called the [[Playlist]]
  * the [[build process|BuildProcess]] is driven, configured and controlled by the [[Controller]] subsystem component. It encompasses the actual playback configuration and State of the System.
@@ -1928,8 +2006,8 @@ see also: RenderEntities, [[two Examples (Object diagrams)|Examples]]
 <!--}}}-->
    -
    -
    A ParamProvider is the counterpart for (one or many) Parameter instances. It implements the value access function made available by the Parameter object to its clients.
+
    
+
    A ParamProvider is the counterpart for (one or many) [[Parameter]] instances. It implements the value access function made available by the Parameter object to its clients.
 
 To give a concrete example: 
 * a Fade Plugin needs the actual fade value for Frame t=xxx
@@ -1941,8 +2019,8 @@ To give a concrete example:
 &rarr; see the class diagram for [[Automation]]
 
    
 
    
-
    
-
    Parameters are all probably variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application state to take effect.
+
    
+
    Parameters are all possibly variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application (or session) state to take effect.
 
 A ''Parameter Object'' provides a descriptor of the kind of parameter, together with a function used to pull the //actual value// of this parameter. Here, //actual// has a two-fold meaning:
 * if called without a time specification, it is either a global (but variable) system or session parameter or a default value for automated Parameters. (the intention is to treat this cases uniformly)
@@ -2621,11 +2699,11 @@ We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes and T
 //Note, we have yet to specify how exactly the building and rendering will work together with the backend. There are several possibilities how to structure the Playlist//
 
    
 
    
-
    
+
    
 
    Open issues, Things to be worked out, Problems still to be solved... 
 
 !!Parameter Handling
-The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime.
+The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime. (&rarr; see [[tag:automation|automation]])
 
 ''Automation Type'': Directly connected is the problem of handling the //type// of parameters sensible, including the value type of automation data. My first (somewhat naive) approach was to "make everything a double". But this soon leads into quite some of the same problems haunting the automation solution implemented in the current Cinelerra codebase. What makes the issue difficult is the fact we both need static diversity as well as dynamic flexibility. Usually, when combining hierarchies and templates, one has to be very careful; so I just note the problem down at the moment and will revisit it later, when I have a more clear understanding of the demands put onto the [[ProcNode]]s
 
@@ -2706,8 +2784,19 @@ The system is ''open'' inasmuch every part mirrors the structure of correspondin
 &rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
 
    
 
    
-
    
+
    
 
    A data processing node within the Render Engine. Its key feature is the possibility to pull from it one (freely addressable) [[Frame]] of calculated data. Further, each ~ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
+
+!! {{red{open questions}}}
+* how to address a node
+* how to type them
+* how to discover the number and type of the ports
+* how to discover the possible parameter ports
+* how to define and query for additional capabilities
+
+&rarr; see also the [[open design process draft|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface]]
+&rarr; see [[mem management|ManagementRenderNodes]]
+&rarr; see RenderProcess
 
    
 
    
 
    
@@ -2996,18 +3085,116 @@ At first sight the link between asset and clip-MO is a simple logical relation b
 &rarr; OverviewRenderEngine
 
    
 
    
-
    
-
    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 [[Processing Nodes|ProcNode]] 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.
+
    
+
    The [[Render Engine|Rendering]] 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 [[Processing Nodes|ProcNode]] 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.
 
 [img[Entities comprising the Render Engine|uml/fig128389.png]]
 
    
 
    
-
    
-
    {{red{TODO: describe the Render Process.}}}
+
    
+
    Below are some notes regarding details of the actual implementation of the render process and processing node operation. In the description of the [[render node operation protocol|NodeOperationProtocol]] and the [[mechanics of the render process|RenderMechanics]], these details were left out deliberately.
 
- * see also the [[Entities involved in Rendering|RenderEntities]]
+!Layered structure of State
+State can be seen as structured like an onion. All the [[StateAdapter]]s in one call stack are supposed to be within one layer: they all know of a "current state", which in turn is a StateProxy (and thus may refer yet to another state, maybe accros the network or in the backend or whatever). The actual {{{process()}}} function "within" the individual nodes just sees a single StateAdapter and thus can be thought to be a layer below.
+
+!Buffer identification
+For the purpose of node operation, Buffers are identified by a //Buffer-handle,// which contains both the actual buffer pointer and an internal indes and classification of the source providing the buffer; the latter information is used for deallocation. Especially for calling the {{{process()}}} function (which is supposed to be plain C) the respective StateAdapter provides an array containing just the output and input buffer pointers
+
+!Problem of multi-channel nodes
+Some data processors simply require to work on multiple channels simultanously, while others work just on a single channel and will be replicated by the builder for each channel invoved. Thus, we are struck with the nasty situation that the node graph may go through some nodes spanning the chain of several channels. Now the decision is //not to care for this complexity within a single chain calculating a single channel.// We rely solely on the cache to avoid duplicated calculations. When a given node happens to produce multiple output buffers, we are bound to allocate them for the purpose of this nodes {{{process()}}} call, but we just "let go" the buffers not needed immediately for the channel acutally to be processed. For this to work, it is supposed that the builder has wired in a caching, and that the cache will hit when we touch the same node again for the other channels.
+
+!Configuration of the processing nodes
+[>img[uml/fig132357.png]]
+Every node is actually decomposed into three parts
+* an interface container of a ProcNode subclass
+* an {{{const}}} WiringDescriptor, which is actually parametrized to a subtype encoding details of how to carry out the intended operation
+* the Invocation state created on the stack for each {{{pull()}}} call. It is comprised of references to an StateAdapter object  and the current overall process state, the WiringDescriptor, and finally a table of suitable buffer handles
+Thus, the outer container can be changed polymorphically to support the different kinds of nodes (large-scale view). The actual wiring of the nodes is contained in the WiringDescriptor, including the {{{process()}}} function pointer. Additionally, this WiringDescriptor knows the actual type of the operation Strategy, and this actual type has been chosen by the builder such as to select details of the desired operation of this node, for example caching / no caching or maybe ~OpenGL rendering or the special case of a node pulling directly from a source reader. Most of this configuration is done by selecting the right template specialisation within the builder; thus in the critical path most of the calls can be inlined
+
+!!!! composing the actual operation Strategy
+As shown in the class diagram to the right, the actual implementation is assembled by chaining together the various policy classes governing parts of the node operation, like Caching, in-Place calculation capability, etc. (&rarr; see [[here|WiringDescriptor]] for details). The rationale is that the variable part of the Invocation data is allocated at runtime directly on the stack, while a precisely tailored call sequence for "calculating the predecessor nodes" can be defined out of a bunch of simple building blocks. This helps avoiding "spaghetti code", which would be especially dangerous because of the large number of different execution paths to get right. Additionally, a nice side effect of this implementation technique is that a good deal of the implementation is eligible to inlining.
+We //do employ//&nbsp; some virtual calls for the buffer management in order to avoid coupling the policy classes to the actual number of in/out buffers. (As of 6/2008, this is mainly a precaution to be able to control the number of generated template instances. If we ever get in the region of several hundred individual specialisations, we'd need to separate out the allocation of the "buffer table" into a hand-made stack-like buffer allocated from the heap.)
+
+!Rules for buffer allocation and freeing
+* only output buffers are allocated. It is //never necessary//&nbsp; to allocate input buffers!
+* buffers are to be allocated as late as possible, typically just before invoking {{{process()}}}
+* buffers are allways allocated by calling to the preceeding StateAdapter in the callstack ("parent stae"), because of the possibility of writing the result to cache.
+* {{{pull()}}} returns a handle for the single output requested by this call. Using this ID, the caller may retrieve the actual buffer holding the result from the "current state" StaeProxy.
+* any other buffers filled with results in the course of the same {{{process()}}} call can be released immediately before returning from the {{{pull()}}}
+* similar, and input buffers are to be released immediately after the {{{process()}}} call, but before returing from this {{{pull()}}}
+* buffers are allways released by calling to the "current state" (which is a StateProxy), providing the buffer-ID to be released
+
+@@clear(right):display(block):@@
 
    
 
    
+
    
+
    While the render process, with respect to the dependencies, the builder and the processing function is sufficiently characterized by referring to the ''pull principle'' and by defining a [[protocol|NodeOperationProtocol]] each node has to adhere to &mdash; for actually get it coded we have to care for some important details, especially //how to manage the buffers.// It may well be that the length of the code path necessary to invoke the individual processing functions is finally not so important, compared with the time spent at the inner pixel loop within these functions. But my guess is (as of 5/08), that the overall number of data moving and copying operations //will be//&nbsp; of importance.
+
+!requirements
+* operations should be "in place" as much as possible
+* because caching necessitates a copy, the points where this happens should be controllable.
+* buffers should accommodate automatically to provide the necessary space without clipping the image.
+* the type of the media data can change while passing through the network, and so does the type of the buffers.
+On the other hand, the processing function within the individual node needs to be shielded from these complexities. It can expect to get just //N~~I~~// input buffers and //N~~O~~// output buffers of required type. And, moreover, as the decision how to organize the buffers certainly depends on non-local circumstances, it should be preconfigured while building.
+
+!data flow
+[>img[uml/fig131973.png]]
+Not everything can be preconfigured though. The pull principle opens the possibility for the node to decide on a per call base what predecessor(s) to pull (if any). This decision may rely on automation parameters, which thus need to be accessible prior to requesting the buffer(s). Additionally, in a later version we plan to have the node network calculate some control values for adjusting the cache and backend timings &mdash; and of course at some point we'll want to utilize the GPU, resulting in the need to feed data from our processing buffers into some texture representation.
+
+!buffer management
+Besides the StateProxy representing the actual render process and holding a couple of buffer (refs), we employ a lightweight adapter object in between. It is used //for a single {{{pull()}}}-call// &mdash; mapping the actual buffers to the input and output port numbers of the processing node and for dealing with the cache calls. While the StateProxy manages a pool of frame buffers, this interspersed adapter allows us to either use a buffer retrieved from the cache as an input, possibly use a new buffer located within the cache as output, or (in case no caching happens) to just use the same buffer as input and output for "in-place"-processing. The idea is that most of the configuration of this adapter object is prepared in the wiring step while building the node network.
+
+The usage patern of the buffers can be stack-like when processing nodes require multiple input buffers. In the standard case, which also is the simplest case, a pair of buffers (or a single buffer for "in-place" capable nodes) suffices to calculate a whole chain of nodes. But &mdash; as the recursive descent means depth-first processing &mdash; in case multiple input buffers are needed, we may encounter a situation where some of these input buffers already contain processed data, while we have to descend into yet another predecessor node chain to pull the data for the remaining buffers. Care has to be taken //to allocate the buffers as late as possible,// otherwise we could end up holding onto a buffer almost for each node in the network. Effectively this translates into the rule to allocate output buffers only after all input buffers are ready and filled with data; thus we shouldn't allocate buffers when //entering// the recursive call to the predecessor(s), rather we have to wait until we are about to return from the downcall chain.
+Besides, these considerations also show we need a means of passing on the current buffer usage pattern while calling down. This usage pattern not only includes a record of what buffers are occupied, but also the intended use of these occupied buffers, especially if they can be modified in-place, and at which point they may be released and reused.
+__note__: this process outlined here and below is still an simplification. The actual implementation has some additional [[details to care for|RenderImplDetails]]
+
+!!Example: calculating a 3 node chain
+# Caller invokes calculation by pulling from exit node, providing the top-level StateProxy
+# node1 (exit node) builds StateAdapter and calls retrieve() on it to get the desired output result
+# this StateAdapter (ad1) knows he could get the result from Cache, so he tries, but it's a miss
+# thus he pulls from the predecessor node2 according to the [[input descriptor|ProcNodeInputDescriptor]] of node1
+# node2 builds its StateAdapter and calls retrieve()
+# but because StateAdapter (ad2) is configured to directly forward the call down (no caching), it pulls from node3
+# node3 builds its StateAdapter and calls retrieve()
+# this StateAdapter (ad3) is configured to look into the Cache...
+# this time producing a Cache hit
+# now StateAdapter ad2 has input data, but needs a output buffer location, which re requests from its //parent state// (ad1)
+# and, because ad1 is configured for Caching and is "in-place" capable, it's clear that this output buffer will be located within the cache
+# thus the allocation request is forwarded to the cache, which provides a new "slot"
+# now node2 has both a valid input and a usable output buffer, thus the process function can be invoked
+# and after the result has been rendered into the output buffer, the input is no longer needed
+# and can be "unlocked" in the Cache
+# now the input data for node1 is available, and as node1 is in-place-capable, no further buffer allocation is necessary prior to calculating
+# the finished result is now in the buffer (which happens to be also the input buffer and is actually located within the Cache)
+# thus it can be marked as ready for the Cache, which may now provide it to other processes (but isn't allowed to overwrite it)
+# finally, when the caller is done with the data, it signalles this to the top-level State object
+# which forwards this information to the cache, which in turn may now do with the released Buffer as he sees fit.
+[img[uml/fig132229.png]]
+
+@@clear(right):display(block):@@
+__see also__
+&rarr; the [[Entities involved in Rendering|RenderEntities]]
+&rarr; additional [[implementation details|RenderImplDetails]]
+&rarr; [[Memory management for render nodes|ManagementRenderNodes]]
+&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
+
    
+
    
+
    
+
    For each segment (of the effective timeline), there is a Processor holding the exit node(s) of a processing network, which is a "Directed Acyclic Graph" of small, preconfigured, stateless [[processing nodes|ProcNode]]. This network is operated according to the ''pull principle'', meaning that the rendering is just initiated by "pulling" output from the exit node, causing a cascade of recursive downcalls. Each node knows its predecessor(s) an can pull the necessary input from there. Consequently, there is no centralized "engine object" which may invoke nodes iteratively or table driven &mdash; rather, the rendering can be seen as a passive service provided for the backend, which may pull from the exit nodes at any time, in any order (?), and possibly multithreaded.
+All State necessary for a given calculation process is encapsulated and accessible by a StateProxy object, which can be seen as the representation of "the process". At the same time, this proxy provides the buffers holding data to be processed and acts as a gateway to the backend to handle the communication with the Cache. In addition to this //top-level State,// each calculation step includes a small [[state adapter object|StateAdapter]] (stack allocated), which is pre-configured by the builder and serves the purpose to isolate the processing function from the detals of buffer management.
+
+
+__see also__
+&rarr; the [[Entities involved in Rendering|RenderEntities]]
+&rarr; the [[mechanics of rendering and buffer management|RenderMechanics]]
+&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
+
    
+
    
+
    
+
    The rendering of input sources to the desired output ports happens within the &raquo;''Render Engine''&laquo;, which can be seen as a collaboration of Proc-Layer, Backend together with external/library code for the actual data manipulation. In preparation of the RenderProcess, the [[Builder]] as wired up a network of [[processing nodes|ProcNode]] called the ''low-level model'' (in contrast to the high-level model of objects placed within the EDL/Session). Generally, this network is a "Directed Acyclic Graph" starting at the //exit nodes// (output ports) and pointing down to the //source readers.// In Lumiera, rendering is organized according to the ''pull principle'': when a specific frame of rendered data is requested from an exit node, a recursive calldown happens, as each node asks his predecessor(s) for the necessary input frame(s). This may include pulling frames from various input sources and for several time points, thus pull rendering is more powerful (but also more difficult to understand) than push rendering, where the process would start out with a given source frame.
+
+Rendering can be seen as a passive service available to the Backend, which remains in charge what to render and when. Render processes may be running in parallel without any limitations. All of the storage and data management falls into the realm of the Backend. The render nodes themselves are ''completely stateless'' &mdash; if some state is necessary for carrying out the calculations, the backend will provide a //state frame// in addition to the data frames.
    
+
    
 
    
 
    The Session contains all informations, state and objects to be edited by the User. From a users view, the Session is synonymous to the //current Project//. It can be saved and loaded. The individual Objects within the Session, i.e. Clips, Media, Effects, are contained in one (or several) collections within the Session, which we call [[EDL (Edit Decision List)|EDL]]. &rarr; [[Session design overview|SessionOverview]]
 
@@ -3111,11 +3298,15 @@ if (oldText.indexOf("SplashScreen")==-1)
 }
 //}}}
    
 
    
-
    
+
    
+
    A small (in terms of storage) and specifically configured StateProxy object which is created on the stack for each individual {{{pull()}}} call. It is part of the invocation state of such a call and participates in the buffer management. Thus, in a calldown sequence of {{{pull()}}} calls we get a corresponding sequence of "parent" states. At each level, the &rarr; WiringDescriptor of the respective node defines a Strategy how the call is passed on.
    
+
    
+
    
 
    An Object representing a //Render Process// and containing associated state information.
 * it is created in the Controller subsystem while initiating the BuildProcess
 * it is passed on to the generated Render Engine, which in turn passes it down to the individual Processors
 * moreover, it contains methods to communicate with other state relevant parts of the system, thereby shielding the rendering code from any complexities of Thread communication if necessary. (thus the name Proxy)
+* in a future version, it may also encapsulate the communication in a distributed render farm
 
    
 
    
 
    
@@ -3385,8 +3576,8 @@ h1,h2,h3,h4,h5,h6 {
 /*}}}*/
 
    
 
    
-
    
-
    <<timeline better:true maxDays:55 maxEntries:30>>
    
+
    
+
    <<timeline better:true maxDays:55 maxEntries:45>>
    
 
    
 
    
 
    /***
@@ -4452,12 +4643,12 @@ Placements are __resolved__ resulting in an ExplicitPlacement. In most cases thi
 &rarr; [[Definition|Pipe]] and [[handling of Pipes|PipeHandling]]
 
    
 
    
-
    
+
    
 
    Transitions combine the data from at least two processing chains and do this combining in a time varying fashion. So, any transition has
 * N input connections
 * either one or N output connections
 * temporal coordinates (time, length)
-* some control data connection to a ParamProvider, because in the most general case the controling curves are treated like automation
+* some control data connection to a ParamProvider, because in the most general case the controling curves are treated similar to  [[automation data|AutomationData]]
 
 !!!how much output ports?
 The standard case of a transition is sort of mixing together two input streams, like e.g. a simple dissolve. For this to be of any use, this input streams need to be connected to the same ouput destination before and after the transition (with regards to the timeline), i.e. the inputs and the transition share placement to the same output pipe. In this case, when the transition starts, the direct connections can be suspended and the transition will switch in seamlessly.
@@ -4467,10 +4658,10 @@ Using transitions is a very basic task and thus needs viable support by the GUI.
 Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their "simple" counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output pipes as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a  inconsistently placed transition is just an [[building error|BuildingError]])
 
    
 
    
-
    
+
    
 
    A ''~Meta-Clip'' or ''Virtual Clip'' (both are synonymous) denotes a clip which doesn't just pull media streams out of a source media asset, but rather provides the results of rendering a complete sub-network. In all other respects it behaves exactly like a "real" clip, i.e. it has [[source ports|ClipSourcePort]], can have attached effects (thus forming a local render pipe) and can be placed and combined with other clips. Depending on what is wired to the source ports, we get two flavours:
-* a __placeholder clip__ has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
-* a __nested EDL__ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, this also [[configures the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
+* a __placeholder clip__; has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
+* a __nested EDL __ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, this also [[configures the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
 
 Like any "real" clip, Virtual Clips have a start offset and a length, which will simply translate into an offset of the frame number pulled from the Virtual Clip's source connection or embedded EDL, making it possible to cut, splice, trim and roll them as usual. This of course implies we can have several instances of the same virtual clip with different start offset and length placed differently. The only limitation is that we can't handle cyclic dependencies for pulling data (which has to be detected and flagged as an error by the builder)
 
    
@@ -4521,7 +4712,7 @@ generally speaking, visitors are preferable when the underlying element type hie
 To see an simple example of our "visiting tool", have a look at {{{tests/components/common/visitingtooltest.cpp}}}
 
    
 
    
-
    
+
    
 
    The Intention of this text is to help you understanding the design and to show some notable details.
 
 !!!!Starting Point
@@ -4542,7 +4733,7 @@ This design strives to build each level and subsystem around some central concep
 * albeit being a special form of a Placement, the ExplicitPlacement is treated as a separate concept. With respect to edit operations within the EDL, it can stand for any sort of Placement. On the other hand the Builder takes a list of ~ExplicitPlacements as input for building up the Render Engine(s). This corresponds to the fact that the render process needs to organize the things to be done on a simple two dimensional grid of (output channel / time). The (extended) contract of an ~ExplicitPlacement provides us with this (output,time).
 * on the lower end of the builder, everything is organized around the Concept of a ProcNode, which enables us to //pull// one (freely addressable) Frame of calculated data. Further, the ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
 * the various types of data to be processed are abstracted away under the notion of a [[Frame]]. Basically, a Frame is an Buffer containing an Array of raw data and it can be located by some generic scheme, including (at least) the absolute starting time (and probably some type or channel id).
-* All sorts of (target domain) [[Parameters]] are treated uniformly. There is a distinction between Parameters (which //could// be variable) and Configuration (which is considered to be fixed). In this context, Automation just appears as a special kind of ParamProvider.
+* All sorts of (target domain) [[parameters|Parameter]] are treated uniformly. There is a distinction between Parameters (which //could// be variable) and Configuration (which is considered to be fixed). In this context, [[Automation]] just appears as a special kind of ParamProvider.
 * and finally, the calculation //process// together with its current state is represented by a StateProxy. I call this a "proxy", because it should encapsulate and hide all tedious details of communication, be it even asynchronous communication with some Controller or Dispatcher running in another Thread. In order to maintain a view on the current state of the render process, it could eventually be necessary to register as an observer somewhere or to send notifications to other parts of the system.
 
 !!!!Handling Diversity
@@ -4555,6 +4746,41 @@ In case it's not already clear: we don't have "the" Render Engine, rat
 The &raquo;current setup&laquo; of the objects in the EDL is sort of a global state. Same holds true for the Controller, as the Engine can be at playback, it can run a background render or scrub single frames. But the whole complicated subsystem of the Builder and one given Render Engine configuration can be made ''stateless''. As a benefit of this we can run this subsystems multi-threaded without the need of any precautions (locking, synchronizing). Because all state information is just passed in as function parameters and lives in local variables on the stack, or is contained in the StateProxy which represents the given render //process// and is passed down as function parameter as well. (note: I use the term "stateless" in the usual, slightly relaxed manner; of course there are some configuration values contained in instance variables of the objects carrying out the calculations, but this values are considered to be constant over the course of the object usage).
 
    
 
    
+
    
+
    Each [[processing node|ProcNode]] contains a stateless ({{{const}}}) descriptor detailing the inputs, outputs and predecessors. Moreover, this descriptor contains the configuration of the call sequence yielding the &raquo;data pulled from predecessor(s)&laquo;. The actual type of this object is composed out of several building blocks (policy classes) and placed by the builder as a template parameter on the WiringDescriptor of the individual ProcNode. This happens in the WiringFactory in file {{{nodewiring.cpp}}}, which consequently contains all the possible combinations (pre)generated at compile time.
+
+!building blocks
+* ''Caching'': whether the result frames of this processing step will be communicated to the Cache and thus could be fetched from there instead of actually calculating them.
+* ''Process'': whether this node does any calculations on it's own or just pulls from a source
+* ''Inplace'': whether this node is capable of processing the result "in-place", thereby overwriting the input buffer
+* ''Multiout'': whether this node produces multiple output channels/frames in one processing step
+
+!!implementation
+!!!!Caching
+When a node participates in ''caching'', a result frame may be pulled immediately from cache instead of calculating it. Moreover, //any output buffer//&nbsp; of this node will be allocated //within the cache.// Consequently, caching interferes with the ability of the next node to calculate "in-Place". In the other case, when ''not using the cache'', the {{{pull()}}} call immediately starts out with calling down to the predecessor nodes, and the allocation of output buffer(s) is always delegated to the parent state (i.e. the StateProxy pulling results from this node). 
+
+Generally, buffer allocation requests from predecessor nodes (while being pulled by this node) will either be satisfied by using the "current state", or treated as if they were our own output buffers when this node is in-Place capable.
+
+!!!!Multiple Outputs
+Some simplifications are possible in the default case of a node producing just ''one single output'' stream. Otherwise, we'd have to allocate multiple output buffers, and then, after processing, select the one needed as a result and deallocate the superfluous further buffers.
+
+!!!!in-Place capability
+If a node is capable of calculating the result by ''modifying it's input'' buffer(s), an important performance optimization is possible, because in a chain of in-place capable nodes, we don't need any buffer allocations. But, on the other hand, this optimization may collide with the caching, because a frame retrieved from cache must not be modified.
+Without this optimization, in the base case each processing needs an input and an output. Exceptionally, we could think of special nodes which //require// to process in-place, in which case we'd need to provide it with a copy of the input buffer to work on. 
+
+!!!!Processing
+If ''not processing'' we don't have any input buffers, instead we get our output buffers from an external source.
+Otherwise, in the default case of actually ''processing'' out output, we have to organize input buffers, allocate output buffers, call the {{{process()}}} function of the WiringDescriptor and finally release the input buffers.
+
    
+
    
+
    
+
    The purpose of automation is to vary a parameter of some data processing instance in the course of time while rendering. Thus, automation encompasses all the variability within the render network //which is not a structural change.//
+
+
+!Parameters and Automation
+
+[[Automation]] is treated as a function over time. Everything beyond this definition is considered an implementation detail of the [[parameter provider|ParamProvider]] used to yield the value. Thus automation is closely tied to the concept of a [[Parameter]], which also plays an important role in the communication with the GUI and while [[setting up and wiring the render nodes|BuildRenderNode]] in the course of the build process (&rarr; see [[tag:Builder|Builder]])
    
+
    OperationClassDescription
    allocateBufferState
    applyBuildable
    applyVisitable
    buildAssembler
    buildEngineBuilderFacadeMain Operation of the Builder: create a render engine for a given part of the timeline
    buildProcessorPathManager
    callDownNodeWiring
    callDownWiringDescriptor
    chainPlacementcreate and add another Placement for this media object, thus increasingly constraining the (possible) position of this object.
    clearSessManagerclear current session contents
    without resetting overall session config.
    Afterwards, the session will contain only one
    empty EDL, while all Assets are retained.
    configureToolFactory
    currEDLSessionThe EDL currently in focus. In most cases, Session and EDL are almost the same, just EDL emphasizes the collection aspect. But generally (for larger editing projects) one Session can contain several EDLs, which may even be nested. At any given time, only one of these EDLs has focus and recieves the editing commands.
    dispatchOpVisitable
    enableAssetchange the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well
    fetchState
    findTypeHandler
    getAppconfigaccess the configuation value for a given key.
    @return empty string for unknown keys, else the corresponding configuration value
    get_reprAllocation
    getValueParamProvider
    howtoProcMedia@return descriptor how to build a render pipeline corresponding to this media
    isActiveAssetweather this asset is swithced on and consequently included in the fixture and participates in rendering
    isCalculatedState
    knownAssetManager@return true if the given id is registered in the internal asset DB
    loadSessManagerreplace the current session by a new
    session loaded from serialized state.
    makeTypeHandler
    playRenderEngineTODO: will probably be handled differently (see Cehteh)
    processProcNode
    pullProcNode
    releaseBufferState
    removeAssetManagerremove the given asset <i>together with all its dependants</i> from the internal DB
    resetSessManagerreset all session config and
    start with a pristine default session.
    resolvePlacementcreate an actual (explicit) placement while trying to satisfy the network of adjacent objects and placements.
    resolveQueryHandler
    resolveQueryHandlerImpl
    retrieveStateAdapter
    rootCauseErrorIf this exception was caused by a chain of further exceptions,
    return the first one registered in this throw sequence.
    This works only, if every exceptions thrown as a consequence
    of another exception is propperly constructed by passing
    the original exception to the constructor
    saveSessManagercreate a complete, serialized representation
    of the current session config and contents.
    @todo how to serialize, prameters, return value?
    treatApplicable
    treatBuilderToolThis operation is to be overloaded for the specific MObject subclasses to be treated.
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatSegmentationTool
    treatSegmentationTool
    treatSegmentationTool
    treatSegmentationTool
    useFileFileProviderAnnounces that the application intends to use this file with mode (READ|WRITE|READWRITE)
    useTemporaryStorageFileProviderProvides a pool for interminate frames
    whatError