Open jkeon opened 1 year ago
What does this get us? Reduced instances where we have to wait 1 frame? Or is this just a performance optimization?
In the example:
We have 4 frames to execute the whole thing, with 4 jobs and 4 data streams.
Whereas we could do:
And everything drops to 3. 25% reduction across memory usage, code authoring and maintenance, and frames waiting.
As the chain increases in nesting, Navigate->FollowPath->Move for example, that compounds. We don't need the intermediate step jobs and data streams that only exist to pipe data down.
TaskDriverSystem jobs are able to Resolve back "UP" the chain to a specific context TaskDriver.
Ex.
TimerTaskDriverA TimerTaskDriverB TimerTaskDriverC TimerTaskDriverSystem
The System executes jobs that run on instances that came from A, B and/or C and when complete, will write that complete back to the correct A, B or C complete stream.
Sometimes we want to be able to kick the result of that System job "DOWN" the chain to another System or another TaskDriver that is a child of A, B, C.
Assume that A, B, C had some sub-task driver each of MoreProcessingD, MoreProcessingE, and MoreProcessingF respectively and was governed by a MoreProcessingSystem.
Today, we need to get the result from TimerTaskDriverSystem and write to TimerTaskDriverA::TimerComplete and then have a job that kicks off that to write into MoreProcessingSystem via MoreProcessingD.
We'd like to be able to bypass that and have TimerTaskDriverSystem write directly to MoreProcessingSystem and know the context is MoreProcessingD by virtue of it being the sub-taskdriver of TimerTaskDriverA.
We should be able to do this by building the lookup of targets based on the new DataTargetIDs.