diff --git a/src/proc/asset/meta/time-grid.cpp b/src/proc/asset/meta/time-grid.cpp index dea09cb91..b0b41f2c1 100644 --- a/src/proc/asset/meta/time-grid.cpp +++ b/src/proc/asset/meta/time-grid.cpp @@ -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_)) { diff --git a/tests/41asset.tests b/tests/41asset.tests index c218522fa..a117cd120 100644 --- a/tests/41asset.tests +++ b/tests/41asset.tests @@ -70,6 +70,7 @@ return: 0 END -PLANNED "Simple TimeGrid" TimeGridBasics_test < #include -//#include -//#include +#include -//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))); } - - }; diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 013b42c4d..85651f235 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -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 "new" and "delete" 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. -
-
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
+

+
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 &rarr; a type system for describing and relating media data streams
+* ScaleGrid &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 "drop off" 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 "drop off" the new meta asset instance. The same procedure is used for augmenting or superseding an existing element.
 

 

 

@@ -6746,7 +6746,7 @@ Question is: how fine grained and configurable needs this to be?
-
+
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 &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 &rarr; always using smart-ptr
 * maybe coin a //value handle// -- to tie the three required parts together