ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix some problems with OutputSlotProtocol_test

Browse source 
still WIP...
 - there is a logical contradiction with the frame numbers
 - somehow, in diagnostics, we access the wrong sequence instance
This commit is contained in:
Fischlurch 2012-01-07 06:40:21 +01:00
parent 5cc034d26b
commit 73cfef69c8
3 changed files with 2 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -85,6 +85,7 @@ namespace meta {
PQuant quantiser (dynamic_pointer_cast<const Quantiser>(gridImplementation));
Literal bindingID (cStr(newGrid.ident.name));
advice::Provision<PGrid>(bindingID).setAdvice(gridImplementation);
advice::Provision<PQuant>(bindingID).setAdvice(quantiser);
return gridImplementation;
}

2
tests/components/proc/play/diagnostic-output-slot.hpp
View file

@ -117,7 +117,7 @@ namespace play {
BuffHandle
trackFrame (FrameID frameNr, BuffHandle const& newBuffer)
{
REQUIRE (contains (frameTrackingIndex_,frameNr),
REQUIRE (!contains (frameTrackingIndex_,frameNr),
"attempt to lock already used frame %lu", frameNr);
frameTrackingIndex_.insert (frameNr);

3
tests/components/proc/play/output-slot-protocol-test.cpp
View file

@ -92,15 +92,12 @@ namespace test {
int64_t frameNr = 123;
BuffHandle buff00 = sink1.lockBufferFor (frameNr);
BuffHandle buff10 = sink2.lockBufferFor (frameNr);
buff00.create<TestFrame>();
buff10.create<TestFrame>();
// rendering process calculates content....
buff00.accessAs<TestFrame>() = testData(0,0);
// while further frames might be processed in parallel
BuffHandle buff11 = sink2.lockBufferFor (++frameNr);
buff11.create<TestFrame>();
buff11.accessAs<TestFrame>() = testData(1,1);
buff10.accessAs<TestFrame>() = testData(1,0);