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

TimeGridBasics_test pass

Browse source
This commit is contained in:
Fischlurch 2011-01-15 15:04:23 +01:00
parent 240c5ac232
commit aa5c78a30f
4 changed files with 24 additions and 39 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
src/proc/asset/meta/time-grid.cpp
View file

@ -112,8 +112,7 @@ namespace meta {
if (predecessor_)
throw error::Invalid("compound and variable time grids are a planned feature"
, error::LUMIERA_ERROR_UNIMPLEMENTED);
if (!fps_)
throw error::Config ("attempt to build a TimeGrid with 0 frames per second");
ENSURE (fps_, "infinite grid was not properly detected by FrameRate ctor");
if (isnil (id_))
{

3
tests/41asset.tests
View file

@ -70,6 +70,7 @@ return: 0
END
PLANNED "Simple TimeGrid" TimeGridBasics_test <<END
TEST "Simple TimeGrid" TimeGridBasics_test <<END
out-lit: simple PAL Grid: (STRUCT/time-scales:lumi.grid_25_1_0:00:00.000 v1)
return: 0
END

43
tests/components/proc/asset/meta/time-grid-basics-test.cpp
View file

@ -26,40 +26,21 @@
#include "proc/asset/meta.hpp"
#include "proc/asset/meta/time-grid.hpp"
#include "proc/asset/asset-format.hpp"
#include "lib/time/timevalue.hpp"
//#include "proc/asset/entry-id.hpp"
//#include "lib/p.hpp"
//#include "proc/assetmanager.hpp"
//#include "proc/asset/inventory.hpp"
//#include "proc/mobject/session/clip.hpp"
//#include "proc/mobject/session/track.hpp"
//#include "lib/meta/trait-special.hpp"
//#include "lib/util-foreach.hpp"
//#include "lib/symbol.hpp"
#include "lib/util.hpp"
//#include <tr1/unordered_map>
#include <boost/rational.hpp>
//#include <iostream>
//#include <string>
#include <iostream>
//using lib::test::showSizeof;
//using lib::test::randStr;
//using util::isSameObject;
//using util::and_all;
//using util::for_each;
//using util::isnil;
using boost::rational_cast;
using lib::test::randStr;
//using lib::Literal;
//using lib::Symbol;
//using lumiera::P;
//using std::string;
//using std::cout;
//using std::endl;
using std::cout;
using std::endl;
namespace asset {
namespace asset{
namespace meta {
namespace test {
@ -83,8 +64,6 @@ namespace test {
* @test build some simple time grids and verify their behaviour
* for quantising (grid aligning) time values.
*
* @todo WIP-WIP-WIP ////////////////////TICKET #736
*
* @see asset::meta::TimeGrid
* @see time-quantisation-test.cpp usage context
*/
@ -114,6 +93,7 @@ namespace test {
PGrid myGrid = spec.commit();
CHECK (myGrid);
CHECK (myGrid->ident.name == myGrID.getSym());
// now verify the grid
// by performing some conversions...
@ -133,9 +113,14 @@ namespace test {
void
createGrid_simplified()
{
PGrid simplePALGrid = TimeGrid::build ("", FrameRate::PAL);
CHECK (simplePALGrid);
CHECK (!util::isnil (simplePALGrid->ident.name)); // note: name-ID filled in automatically
cout << "simple PAL Grid: " << simplePALGrid->ident << endl;
CHECK (Time(2) == simplePALGrid->timeOf(50));
CHECK (Time(2) == simplePALGrid->timeOf(FSecs(2)));
}
};

14
wiki/renderengine.html
View file

@ -2745,10 +2745,10 @@ For the case here in question this seems to be the ''resource allocation is cons
And, last but not least, doing large scale allocations is the job of the backend. Exceptions being long-lived objects, like the session or the sequences, which are created once and don't bear the danger of causing memory pressure. Besides, the ProcLayer code shouldn't issue &quot;new&quot; and &quot;delete&quot; when it comes in hand, rather it should use some centralized [[Factories]] for all allocation and freeing, so we can redirect these calls down to the backend, which may use pooling or special placement allocators or the like. The rationale is, for modern hardware/architectures, care has to be taken with heap allocations, esp. with many small objects and irregular usage patterns.
</pre>
</div>
<div title="MetaAsset" modifier="Ichthyostega" modified="201012302032" created="201012290320" tags="def" changecount="7">
<pre>This category is comprised of the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised.
* StreamType
* ScaleGrid
<div title="MetaAsset" modifier="Ichthyostega" modified="201101151026" created="201012290320" tags="def" changecount="9">
<pre>This category is comprised of the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised (which is the realm of [[structural assets|StructAsset]]
* StreamType &amp;rarr; a type system for describing and relating media data streams
* ScaleGrid &amp;rarr; to manage time scales and frame alignment
!accessing meta assets
It turns out that all meta assets follow a distinct usage pattern: //they aren't built as individual entities.// Either, they are introduced into the system as part of a larger scale configuration activity, or they are //derived from category.// The latter fits in with a prototype-like approach; initially, the individual entry just serves to keep track of a categorisation, while at some point, such a link into a describing category may evolve into a local differentiation of some settings.
@ -2762,7 +2762,7 @@ These observation leads to a design relying on a self referential structure: eac
!!!mutating meta assets
Meta assets are ''immutable'' -- but they can be //superseded.//
For each meta asset instance, initially a //builder// is created for setting up the properties; when done, the builder will &quot;drop off&quot; the new meta asset instance. The same procedure is used augmenting or superseding an existing element.
For each meta asset instance, initially a //builder// is created for setting up the properties; when done, the builder will &quot;drop off&quot; the new meta asset instance. The same procedure is used for augmenting or superseding an existing element.
</pre>
</div>
<div title="Model" modifier="Ichthyostega" modified="201003210021" created="201003210020" tags="overview" changecount="2">
@ -6746,7 +6746,7 @@ Question is: how fine grained and configurable needs this to be?
</pre>
</div>
<div title="TimecodeFormat" modifier="Ichthyostega" modified="201101142138" created="201101100308" tags="Player spec discuss draft" changecount="16">
<div title="TimecodeFormat" modifier="Ichthyostega" modified="201101151404" created="201101100308" tags="Player spec discuss draft" changecount="17">
<pre>The handling of [[Timecode]] is closely related to [[time representation and quantisation|TimeQuant]]. In fact, these two topics blend into one another. Time will be quantised into a //grid,// but this grid only makes sense when linked to a externally relevant meaning and representation, which is the Timecode. But a timecode value also denotes a specific point in time -- performing operations on a timecode is equivalent to manipulating a quantised time value.
!Problem of dependencies
@ -6772,7 +6772,7 @@ And last but not least, it is possible to get a new ~TimeValue, reflecting the c
* @@color:green;✔@@ find out about the connection to the MetaAsset &amp;rarr; [[Advice]]
* @@color:green;✔@@ determine the primitives which need to be on the //effective quantiser API.//
* find out how a format can address the individual components it's comprised of
* decide how a concrete TC value can refer to his quantiser
* @@color:green;✔@@ decide how a concrete TC value can refer to his quantiser &amp;rarr; always using smart-ptr
* maybe coin a //value handle// -- to tie the three required parts together
</pre>
</div>