From 608ae3efd8abd3b948024c884d937784122d2b43 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 16 Nov 2013 20:23:02 +0100 Subject: [PATCH] continue development where we left before the release effort --- src/proc/engine/dispatcher.hpp | 17 +++++++++-------- src/proc/engine/job-planning.hpp | 6 +++--- .../proc/engine/dispatcher-interface-test.cpp | 2 +- 3 files changed, 13 insertions(+), 12 deletions(-) diff --git a/src/proc/engine/dispatcher.hpp b/src/proc/engine/dispatcher.hpp index 6d3c59ebd..36f9989da 100644 --- a/src/proc/engine/dispatcher.hpp +++ b/src/proc/engine/dispatcher.hpp @@ -58,13 +58,14 @@ namespace engine { * * \par usage considerations * the asynchronous and ongoing nature of the render process mandates to avoid a central - * instance for operating this planning process. Instead, each chunk of planned jobs - * contains a continuation job, which -- on activation -- will pick up the planning - * of the next chunk. The Dispatcher interface was shaped to support this process, - * with a local JobBuilder to be used within the continuation job, and a TimeAnchor - * to represent the continuation point. All the complexities of planning jobs are - * hidden within the JobPlanningSequence, which, for the purpose of dispatching - * a series of jobs just looks like a sequence of job descriptors + * instance for operating this planning process. Instead, together with each chunk of + * planned jobs we generate a continuation job, which -- on activation -- will pick up + * the planning of the next chunk. The Dispatcher interface was shaped especially to + * support this process, with a local JobBuilder for use within the continuation job, + * and a TimeAnchor to represent the continuation point. All the complexities of + * actually planning the jobs are hidden within the JobPlanningSequence, + * which, for the purpose of dispatching a series of jobs just looks + * like a sequence of job descriptors * * @todo 10/12 still WIP, but conceptually settled by now */ @@ -99,7 +100,7 @@ namespace engine { virtual FrameCoord locateRelative (FrameCoord, uint frameCountOffset) =0; virtual FrameCoord locateRelative (TimeAnchor, uint frameCountOffset) =0; //////////TODO is this really an interface operation, or just a convenience shortcut? - virtual bool seamlessNextFrame (int64_t, ModelPort port) =0; + virtual bool isEndOfChunk (int64_t, ModelPort port) =0; ////////TODO: API-1 = just get next frame, without limitations .... CHECK ////////TODO: API-2 = query limitation of planning chunk .... CHECK diff --git a/src/proc/engine/job-planning.hpp b/src/proc/engine/job-planning.hpp index f57c18812..2ab2053cd 100644 --- a/src/proc/engine/job-planning.hpp +++ b/src/proc/engine/job-planning.hpp @@ -302,13 +302,13 @@ namespace engine { bool canContinue (FrameCoord const& location) { - return seamlessNextFrame (location.absoluteFrameNumber, - location.modelPort); + return !isEndOfChunk (location.absoluteFrameNumber, + location.modelPort); } protected: virtual JobTicket& accessJobTicket (ModelPort, TimeValue nominalTime) =0; - virtual bool seamlessNextFrame (int64_t, ModelPort port) =0; + virtual bool isEndOfChunk (int64_t, ModelPort port) =0; }; diff --git a/tests/core/proc/engine/dispatcher-interface-test.cpp b/tests/core/proc/engine/dispatcher-interface-test.cpp index 20869f5b2..24507d41c 100644 --- a/tests/core/proc/engine/dispatcher-interface-test.cpp +++ b/tests/core/proc/engine/dispatcher-interface-test.cpp @@ -96,7 +96,7 @@ namespace test { } bool - seamlessNextFrame (int64_t, ModelPort port) + isEndOfChunk (int64_t, ModelPort port) { UNIMPLEMENTED ("determine when to finish a planning chunk"); }